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BY 


ALAN  C.H.  KAM 

UNIVERSITY  OF  HAWAII,  HONOLULU 


THIS  REPORT  IS  A  COLLECTION  OF  INTERNAL 
REPORTS  DEALING  WITH  THE  LIBRARY  MANAGEMENT.  THE 
PRELIMINARY  DESIGN  DETAILS  THE  ANTICIPATED  SYSTEM. 
THE  STRUCTURE  OF  DATA  BASE  REVEALS  THE 
IMPLEMENTATION  SCHEME  ON  AN  IBM  2314  DISK  FACILITY. 
VARIOUS  ALGORITHMS  ARE  PRESENTED  TO  DOCUMENT  THE 
ACTUAL  SYSTEM  CONDITIONED  BY  USING  XPL  AND  OS 
MVT/HASP.  FINALLY  A  DETAILED  DESCRIPTION  OF  THE  XPL 
PROGRAM  ELABORATES  UPON  THE  MODULAR  APPROACH. 
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THIS  WORK  IS  A  JOINT  PROJECT  OF  THE  UNIVERSITY  OF 
HAWAII  COMPUTING  CENTER  AND  THE  ALOHA  SYSTEM,  A  RESEARCH 
PROJECT  RESEARCH  (SRMA)  UNDER  CONTRACT  NUMBER  F44620-69-C- 
0030,  OF  THE  UNIVERSITY  OF  HAWAII*  SUPPORTED  BY  THE  OFFICE 
OF  AEROSPACE  A  PROJECT  THEMIS  AWARO. 
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ABSTRACT 


Th6  UHTSS  USER'S  LIBRARY  IS  A  COLLECTION  OF  USER'S  DATA 
SETS  WHOSE  FORMAT  IS  EITHER  SOURCE  {80  BYTE  CARO  IMAGE 
RECORDS)  OR  LOADABLE  13000  BYTE  CORE  IMAGE  RECORDS).  EACH 
USER'S  DATA  SET  IS  AN  INDEXED  LIST  OF  LOGICAL  TRACKS  13520 
BYTES  =  1/2  PHYSICAL  TRACK).  THE  LIBRARY  PROVIDES  SIMPLE 
EDITING  FUNCTIONS  FOR  SOURCE  DATA  SETS,  ROUTES  SOURCE  DATA 
SETS  TO  EXTERNAL  OEVICES,  AND  MANAGES  THE  DATA  SETS.  THIS 
PROGRAM  IS  WRITTEN  IN  XPL  USING  THE  DIRECT  ACCESS  FEATURES. 
THE  LIST  PROCESSING  ASPECTS  OF  TSS-LIBRARY  ARE  USER  WRITTEN 
SINCE  THE  XPL  FACILITIES  ARE  INADEQUATE.  IN  PARTICULAR, 
ARRAY  MANIPULATION  AND  STRING  MOVE  FUNCTIONS  ARE  CODED  AS 
XPL  PROCEDURES. 

THE  MANAGEMENT  OF  THE  LIBRARY  CONSISTS  OF  "CREATING" 
DATA  SETS,  "SCRATCHING"  DATA  SETS,  "SELECTING"  DATA  SETS, 
AND  "NAMING"  DATA  SETS. 

ONCE  A  DATA  SET  HAS  BEEN  CREATED/ SELECTED ►  ONE  MAY 
ENTER  SOURCE  CAROS  ONTO  HIS  DATA  SET.  TWO  EDIT  I ho  FUNCTIONS 
PROVIDE  A  SIMPLE  METHOD  TO  ACCOMPLISH  THE  UPDATING.  A  SOURCE 
CARD  IS  A  72  BYTE  IMAGE  WITH  A  6  BYTE  KEY.  THE  KEY  SEQUENCES 
THE  POSITION  OF  THE  CARO  WITHIN  THE  DATA  SET.  "INSERT"  ADDS 
A  CARD  TO  OR  REPLACES  A  CARO  IN  THE  DATA  SET,  WHILE  "DELETE" 
REMOVES  A  CARD  FROM  THE  DATA  SET.  BOTH  CREATION  AND 
INSERTION  UTILIZE  THE  TRACK  ALLOCATOR,  WHILE  SCRATCHING  AND 
OELETIQN  USE  THE  TRACK  FREER*  THE  TRACK  MANAGEMENT  ROUTINES 
CHECK  POINT  THE  IN-CORE  TABLE  ONTO  THE  DISK  FILE  EACH  TIME 
THE  TABLE  ENTRIES  ARE  ALTERED. 

NOW  IF  THfc  USER  HAS  FINALLY  DEBUGGED  HIS  PROGRAM  AND 
WANTS  TO  REVIEW  IT,  TSS-LIBRARY  PROVIDES  THIS  FUNCTION.  IN 
GENERAL,  SOURCE  DATA  SETS  CAN  BE  ROUTED  TO  THE  BATCH 
PROCESSOR  AND  TO  3  EXTERNAL  OEVICES  -  PRINTER,  PUNCH,  AND 
HIS  TERMINAL.  USING  THE  ROUTING  ROUTINES,  THE  USER  CAN 
OBTAIN  A  PERMANENT  HARO  COPY  OF  HIS  PROGRAMS.  THE  RESPECTIVE 
COMMANDS  ARE  'HASP',  'PRINT',  'PUNCH',  AND  'DISPLAY*. 

FINALLY  THE  USER  MAY  USE  INTERNAL  COMMANDS  WHICH 
MANIPULATE  THE  CONTENTS  LOGICAL  TRACKS.  HE  CAN  SELECT  OATA 
SETS  USING  "LINK",  READ  A  LOGICAL  TRACK  RECORD  BY  USING 
"LOAD",  AND  WRITE  A  LOGICAL  TRACK  RECORO  BY  USING  "OAOL". 
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SYSTEM  OVERVIEW 


JLUlIBflBUCIIflM 


WITH  THE  INSTALLATION  OF  THE  MVT  OPERATING  SYSTEM  ON 
THE  UH  IBM  360/65,  THE  TIMESHARING  SYSTEM  DEVELOPED  HERE  FOR 
USE  WITH  THE  MODEL  50  BECAME  OBSOLETE.  A  NEW  SYSTEM,  UHTSS, 
IS  NOW  UNDER  DEVELOPMENT  AS  A  JOINT  PROJECT  OF  THE  COMPUTING 
CENTER  ANO  THE  ALOHA  SYSTEM.  UHTSS  CURRENTLY  UTILIZES  IBM 
2260s S,  ANO  SHOULD  BE  EASILY  ADAPTABLE  TO  ANY  KIND  OF 
TERMINAL  WE  ACQUIRE. 

UHTSS  HAS  A  CONSOLE  USER'S  DATA  FILE  ST  JCTURED  TO 
FACILITATE  EDITING  FROM  THE  CONSOLE.  DATA  SET*  OF  CARD 
IMAGES  CAN  BE  CREATED,  EXAMINED  AND  EDITED  FROM  THE  CONSOLE 
ANO  PRINTED,  PUNCHED,  OR  READ  BY  A  CONSOLE  OR  BACKGROUND 
PROGRAM.  CONSOLE  USER'S  QATA  SETS  CAN  ONLY  BE  ACCESSEO  BY 
UHTSS  UTILITY  ROUTINES,  BECAUSE  THEY  DO  NOT  USE  A  STANDARD 
IBM  ACCESS  METHOD.  THE  SYSTEM  WILL  ALSO  BE  ABLE  TO  USE 
STANDARD  IBM  CS  DATA  SETS,  BUT  THE  FILL  FACILITY  FOR  THIS 
WILL  REQUIRE  CONSIDERABLE  TIME  TO  DEVELOP. 

PROGRAMS  CAN  BE  EXECUTEO  IN  THREE  MODES*  FIRST,  THE 
VERY  HEAVILY  USED  ROUTINES  FOR  DISPLAYING  AND  EDITING 
CONSOLE  USERS'  DATA  SETS  WILL  BE  IN  THE  MEMORY  ALL  THE  TIME. 
SECONDLY,  A  PART  OF  THE  MEMORY  WILL  BE  AVAILABLE  TO  SHARE 
AMONG  CONSOLE  USERS  BY  ’•SWAPPING"  TO  THE  DISK  UNIT.  THIS 
WILL  BE  USED  FOR  VERY  SHORT  PROGRAMS  ANO  INTERACTIVE 
PROGRAMS •  THIRDLY,  A  PERSON  WILL  BE  ABLE  TO  PREPARE  A 
PROGRAM  IN  MUCH  THE  SAME  MANNER  AS  FOR  ORDINARY  BATCH 
OPERATION  AND  SUBMIT  IT  TO  THE  BATCH  OPERATION  BY  COMMANDS 
FROM  THE  CONSCLE. 

OUR  OLO  TIME-SHARING  SYSTEM  USEO  STANDARD  BATCH 
COMPILERS.  IT  IS  Ml  OUR  INTENTION  TO  INCLUDE  THIS  FACILITY 
WITH  THE  NEW  SYSTEM,  BUT  TO  PROVIDE  COMPILERS  OR 
INTERPRETERS  ADAPTED  PRIMARILY  TO  TIME-SHARING  SYSTEMS.  THE 
BATCH  COMPILERS  ARE  MOST  GENEr  «l  BUT  ARE  AWKWARD  ...<D  SLOW 
FOR  USE  WITH  THE  2260.  FUTHERMORE,  THEIR  USE  WITH  A 
TYPEWRITER  CONSOLE  WILL  BE  MUCH  MORE  DIFFICULT.  CURRENTLY,  A 
BASIC  COMPILER  ANO  A  DESK  CALCULATOR  FACILITY  ARE  AVAILABLE. 


THE  PRELIMINARY  DESIGN  OF  THE  LIBRARY  MANAGEMENT  MAS 
BASED  ON  A  GRANDIOSE  VIEW  OF  AN  INFORMATION  RETRIEVAL 
SYSTEM.  IT  WAS  CONDITIONED  BY  IBM'S  DATA  MANAGEMENT  SYSTEMS 
AND  IN  PARTICULAR  PARTITIONED  DATA  SETS.  AFTER  INVESTIGATING 
THE  POS  SCHEME,  THE  FOLLOWING  CONCLUSION  WAS  DRAWN:  IT  WON'T 
WORK.  THE  MAIN  REASON  FOR  THIS  STATEMENT  WAS  THAT  THE  PDS 
SCHEME  LACKED  DYNAMIC  GAR8AGE  COLLECTION  (WHICH  IBM  CALLS 
DEGASSING).  THUS  THIS  FIRST  EFFORT  IN  SPECIFYING  WHAT  WAS 
CESiaCC  "ETLECT  tD  ONLY  ASPIRATIONS  ON  THE  GROSSEST  SCALE. 
YET,  ITS  LOGIC  HAS  PREVAILED  WITHIN  THE  UHfSS  LIBRARY 
SCHEME. 

THE  COMMAND  STRUCTURE  REFLECTED  A  MOOEST  ASPECT  OF  THE 
PRELIMINARY  DESIGN.  THE  COMMANDS  PROVIDEO  SIMPLE  FUNCTIONS, 
MAINLY  THOSE  REQUIREO  TO  MANIPULATE  CARD  IMAGED  DATA  SETS. 
THE  LIBRARY  SCHEME  WAS  STRUCTURED  TO  THIS  END. 

THE  DATA  BASE  STRUCTURE  WAS  A  STRAIGHTFORWARD  SCHEME 
DESIGNED  TO  MINIMIZE  DISK  ACCESSES.  THE  RETRIEVAL  SCHEME  WAS 
PREDICATED  UPON  THE  EXISTANCE  OF  SEARCH  KEYS.  IN  ORDER  TO 
ACCESS  A  SINGLE  CARD  THE  FOLLOWING  KEYS  WERE  AT  ONE  TIME 
USED:  THE  JOB/ACCOUNT  NUMBER  KEY,  THE  DATA  SET  NAME  KEY,  AND 
THE  CARD  KEY.  THIS  LIBRARY  PLAN  DIFFERED  FROM  MANY  TIME¬ 
SHARING  SYSTEMS  BY  NOT  COPYING  THE  USER'S  FILE  ONTO  A  WORK 
FILE,  EDITING  THAT  FILE  ANO  LATER  RECOPYING  THE  EDITED  ONE 
ONTO  THE  ORIG  WAL,  BUT  BY  PERFORMING  ALL  EDITING  IN-PLACE. 

WITH  THIS  DATA  BASE,  SEVERAL  ALGORITHMS  WERE  DELEVLOPED 
TO  MANAGE  THE  FILE.  HALF  OF  THEM  WERE  QUITE  NATURAL  AND  WERE 
DESIGNED  BEFORE  THE  IMPLEMENTATION.  THE  OTHER  HALF  WERE  BORN 
OUT  OF  NECESSITY. 

THE  XPL  IMPLEMENTATION  USED  A  HORRENDOUS  COLLECTION  OF 
SUBROUTINES.  THE  BASIC  CONCEPT  PREVALENT  THROUGHOUT  THE 
PROGRAM  WAS  THAT  OF  BLOCKS.  BLOCKS  WERE  CREATED,  MGVEO  ABOUT 
AND  OELETED.  THE  VISUAL  APPEARANCE  OF  THE  PROGRAM  WAS 
DESIGNEO  TO  PROVIOE  A  PICTURE  OF  THE  INTERNAL  RELATIONSHIPS. 
SINCE  THE  FLOW  OF  CONTROL  IS  LINEAR,  SOME  EFFORT  WAS 
EXPENOED  TO  LINEARIZE  THE  ALGORITHMS.  NOTE  THAT  BOTH  ERROR 
ANO  NORMAL  EXITS  WERE  LOCALIZED. 

THE  LAST  SEGMENT  OF  THE  OATA  BASE  OVERVIEW  IS  THE  FILE 
MAINTENANCE  ROUTINES.  TWO  OF  THESE  PROGRAMS  USE  THE  DISK  AS 
A  OIRECT  ACCESS  FILE,  NOT  A  UHTSS  LIBRARY  FILE.  THE  OTHER 
PROGRAM,  ANLZOISK,  IS  STILL  IN  ITS  INFANCY.  MUCH  WORK  IS 
REQUIRED  IN  THE  AREA  OF  OISK  SPACE  ACCOUNTING,  DEAD  STORAGE 
MANAGEMENT,  ANO  OATA  SET  REORGANIZATION. 
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AAE&fiammo,  historic 

T HE  BASIC  REASON  FOR  CHOOSING  THE  XPL  SYSTEM  WAS  THAT 
IT  WAS  A  SYTEM  THAT  WE  COULD  UNDERSTAND.  ALTER  AND  RE¬ 
DESIGN.  WE  D  ID  NOT  WANT  TO  PATCH  EXISTING  CQMPLIER  SYSTEMS. 

ALTHOUGH  FORTRAN  H  WOULD  HAVE  GIVEN  US  THE  MOST 
EFFICIENT  CODE.  ITS  STRING  PROCESSING  CAPABILITIES  WERE  NON- 
EXISTANT.  STRING  MANIPULATION  IS  NOT  A  REQUISITE  BUT  ADOS  TO 
THE  STRUCTURAL  RELATIONSHIPS  OF  THE  ROUTINES.  PL/1  WITH  ITS 
LIST  PROCESSING  WOULO  HAVE  BEEN  PERFECT.  HOWEVER,  THE 
OVERHEAD  IN  MNKAGE.  ET  CETERA,  WOULD  HAVE  BEEN  A 
DISADVANTAGE.  WIfH  THE  IMPROVEMENTS  AND  THE  COMMITMENT  MADE 
BY  IBM,  PL/1  HAS  IMPROVED  AND  PERHAPS  WOULO  HAVE  BEEN  THE 
BEST  CHOICE. 

ANOTHER  REASON  FOR  CHOOSING  XPL  WAS  BASED  ON  THE 
OBJECTIVES  OF  THE  PROJECT,  NAMELY  TO  INVESTIGATE  HIGHER- 
LCVEL  LANGUAGES  FOR  TIME-SHARING.  OBVIOUSLY  ONE  MUST  REVAMP 
THE  COMPILER  IN  OROER  TO  PROVIDE  THE  PROPER  STRUCTURING. 
MANUFACTURER'S  COMPILERS  WERE  CLEARLY  TOO  DIFFICULT  TO 
ALTER,  MUCH  LESS  TO  OBTAIN  IN  SOURCE  FORM.  OUR  RECOURSE  WAS 
TO  USE  SMALL,  FAST  BOOTSTRAPPING  COMPILERS.  XPL  WAS  THE  ONLY 
ONE  AVAILABLE  AND  IT  HAD  CONSIDERABLE  DOCUMENTATION. 

THE  ONLY  CHANGE  TO  THE  COMPILER,  TO  OATE,  WAS  THE 
AOOITION  OF  A  SIMPLE  EDITOR  FACILITY.  MOST  SYSTEMS  UPDATE 
THE  MASTER  FILE,  PRODUCE  A  N li  MASTER  FILE,  AND  THEN  COMPILE 
THE  NEW  MASTER  FILE.  THIS  INVOLVES  AN  EXTRA  PASS  THROUGH  THE 
SOURCE  AND  EXTRA  OISK/TAPE  STORAGE.  IT  WAS  CLEAR  THAT  THE 
COMPILER  COULO  BE  EASILY  MODIFIED  TO  PERFORM  THE  MERGE  AND 
COMPILE  AT  THE  SAME  TIME.  IN  THIS  MANNER  A  NEW  MASTER  FILE 
NEED  NOT  BE  CREATEO  UNTIL  ALL  THE  CHANGES  WERE  DEBUGGED. 

THE  UPDATE  PROCESS  INVOLVES  A  SERIES  OF  IMERGE  CAROS 
AND  SETS  OF  UPOATE  CARDS.  A  SET  OF  UPDATE  CAROS  IS  THE  GROUP 
OF  SOURCE  CARDS  BETWEEN  A  PAIR  OF  EMERGE  CAROS.  THESE  SOURCE 
CAROS  CONTAIN  THE  NORMAL  XPL  SOURCE  STATEMENTS  WITHOUT  ANY 
OTHER  REFINEMENTS. 

ALTHOUGH  THE  EMERGE  CAROS  ARE  QUITE  PRIMITIVE,  THE 
BASIC  FUNCTION  HAS  PROVEN  INVALUABLE  IN  OUR  DEBUGGING.  FOR 
ONE  THING,  WE  00  NOT  NEEO  TO  LUG  BOXES  OF  CAROS  TO  BE 
MANGLEO  IN  THE  READER.  SECONOLY,  WE  NEEO  LESS  OS  INTERACTION 
WITH  RESPECT  TO  00  CAROS  IF  WE  USE  SUNOARO  UPDATE 
PROCEDURES.  FINALLY,  LESS  SPACE  ON  THE  OISK  IS  REQUIRED 
SINCE  ONLY  "GOOO"  VERSIONS  WILL  BE  THERE. 


COMMAND  STRUCTURE*  JANUARY  1*  1969 
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DATA  SET  MANAGEMENT  COMMANDS 


THE  FOLLOWING  COMMANDS  MANAGE  THE  UStR'S  DATA  SETS. 
THEY  MAKE  AUXILIARY  STORAGE  AVAILABLE  TO  THE  USER  FOR  OATA 
OR  PROGRAM  RETRIEVAL. 


COMMAND  PARAMETERS 

SELECT  DATA  SET  NAME 

CREATE  OATA  SET  NAME 

NAME  OLO  NAME*  NEW  NAME 


SCRATCH  DATA  SET  NAME 


REMARKS 

THE  SELECTEO  OLO  DATA  SET  IS 
USED  FOR  ENSUING  COMMANDS  SUCH 
AS  DISPLAY ,  EDITING  COMMANOS, 
OR  INPUT  FOR  A  COMPILER  OR 
OTHER  PROGRAM. 

CREATE  A  NEW  DATA  SET  IN  THE 
CONSOLE  USERS  OATA  FILE.  AND 
SELECT  IT.  THE  DATA  SET  WILL  BE 
AUTOMATICALLY  SCRATCHED  AFTER 
AN  ELAPSED  PERIOO  OF  30  DAYS. 

RENAME  OATA  SET.  THIS  COMMAND 
IS  USEFUL  WHEN  A  PROGRAMMER 
OEVELOPES  A  ROUTINE  IN  A  CATA 
SET  ‘TEST*.  WHEN  HIS  IS  FINALLY 
FINISHED  DEBUGGING  TO  PROGRAM, 
HE  CAN  CHANGE  THE  NAME  TO 
•EIGEN* . 

SCRATCH  THE  DATA  SET  FROM  THE 
LIBRARY.  IF  THE  OATA  SET  HAS 
BEEN  CREATED  AND  SCRATCHED 
WITHIN  A  WEEK  THEN  THE  USER 
WILL  NOT  BE  CHARGEO  FOR  THE 
AUXILIARY  STORAGE  SPACE. 


EXAMPLES  OF  EACH  COMMAND  FOLLOWS:  NOTE  THAT  THE 
COMMANOS  MAY  BE  ABBREVIATED  AND  THAT  ONLY  THE  FIRST  8 
CHARACTERS  OF  THE  OATA  SET  NAME  ARE  USEO. 

SELECT  JOHN 

CREATE  PETE 

NA  ICLO  UNEW; 


SCR  MANY 


COMMAND  STRUCTURE •  JANUARY  l ,  1969 


8 


THE  FQLLGWING  COMMANDS  RELATE  TO  DISPLAY  FUNCTIONS.  AT 

ALL  TIMES  THE  OPERATION  IS  ON  THE  LAST  SELECTEO  DATA  SET, 

ANO  FURTHERMORE,  THE  SYSTEM  KEEPS  TRACK  OF  THE  LAST  RECORD 

WHICH  WAS  REFERENCED  BY  A  OISPLAY  OR  EDITING  COMMAND.  THEN  A 

RECORD  CAN  BE  DESIGNATED  IN  ANY  OF  SEVERAL  WAYS. 

OISPLAY  IF  NO  PARAMETER  IS  GIVEN, 

STEP*l  IS  ASSUMED. 

OISPLAY  ALL  DISPLAY  ALL  THE  DATA  SETS  WITH 

THE  SAME  JOB  NUMBER. 

OISPLAY  OATA  SETS  DISPLAY  ALL  OATA  SETS  WITH  THE 

SAME  JOB  NUMBER  ANO  USER'S 
NAME. 

OISPLAY  FIRST  DISPLAY  THE  FIRST  RECORD  IN  THE 

OATA  SET. 

OISPLAY  KEY* X  DISPLAY  THE  RECORD  WHOSE  KEY  IS 

X  (l  TO  6  CHARACTERS).  NOTE 
THAT  'l*  IS  NOT  THE  SAME  AS 
•OP.  IN  FACT  'OOOOOl*  IS  NOT 
THE  SAME  TOO. 

OISPLAY  LAST  OISPLAY  THE  LAST  RECORD  IN  THE 

DATA  SET. 

OISPLAY  NUMBER-N  DISPLAY  ThF  .*IH  RECOPD  IN  THE 

OATA  SET. 

OISPLAY  STEP*N  DISPLAY  THE  NTH  RECQRO  AFTER 

THE  LAST  RECORD  REFERENCED  (OR 
BEFORE  IF  N  IS  NEGATIVE).  IF 
THE  NTH  RECQRO  IS  NOT  WITHIN 
THE  SAVE  DISK  RECORD*  THE  NTH 
RECQRO  BECOMES  THE  LAST  CARD  OF 
THE  DISK  RECORD  (OR  THE  FIRST 
ONE). 

DISPLAY  SURF  OISPLAY  YOUR  JOB/ACCOUNT 

number*  name*  ioc cunts,  cpu 

SECONOS,  OATA  SET  NAME,  ANO 
CURRENT  KEY. 

DISPLAY  TEXT* * XXX '  SEARCH,  STARTING  FROM  THE  LAST 

R6C0R0  REFERENCED.  FOR  THE 
CHARACTER  STRING  XXX,  ANO 
OISPLAY  THE  RECORD  WHICH 
CONTAINS  IT. 


COMMAND  STRUCTURE;  JANUARY  1,  1969 
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JUSPLAY  COMMANDS 

TO  ANY  01  SPLAY  COMMAND,  ANOTHER  PARAMETER  MAY  BE  AOOED 
WHICH  IS  A  NUMBER  WHICH  DESIGNATES  HOW  MANY  RECORDS  SHOULD 
BE  DISPLAYED  (IF  MORE  THAN  ONE).  IF  . OU  DO  NOT  KNOW  HOW  MANY 
RECORDS  ARE  01,  THE  SELECTED  DATA  SET  'LAST*  IS  THE  SAME  AS 
99999.  FOR  EXAMPLE,  TO  DISPLAY  RECORDS  10,  11,  12,  AND  13  OF 
THE  SELECTED  OATA  SET  USE  THE  FOLLOWING  COMMAND: 


DISPLAY  NUMBER  *  10,  4 

TO  SUBMIT  A  JOB  FOR  BATCH  PROCESSING  ONE  ISSUES  THE 
"HASP"  COMMANO.  THE  PARAMETERS  FOR  "HASP"  ARE  THE  SAME  AS 
THOSE  FOR  "DISPLAY".  THE  ENTIRE  OS  JCL  MUST  BE  PASSEO  WITH 
THIS  COMMAND.  FOR  EXAMPLE: 

HASP  FIRST  LAST 

"PRINT"  ANC  "PUNCH"  MAY  REPLACE  THE  "DISPLAY"  VERB. 
"PRINT"  ROUTES  THE  RECORO  TO  BE  PRINTED  WHILE  "PUNCH"  ROUTES 
THE  RECORO  TO  BE  PUNCHED.  THE  SYSTEM  WILL  INSERT  THE 
APPROPRIATE  JCL  CAROS  TO  ACHIEVE  THIS  FUNCTION  AND  SUBMIT 
THE  JOBS  TO  THE  HASP  SYSTEM.  THUS  THE  FUNCTIONS  (PRINT  AND 
PUNCH)  ARE  LIMITEO  TO  2000  LINES  ANO  1000  CARDS.  FOR 
EXAMPLE: 


PRINT  TEXT  *  'AN  APOSTROPHE  ••  IS  0K."» 

NOTES:  TO  TERMINATE  A  DISPLAY  IN  EXECUTION,  CAUSE  AN 
INTERRUPT.  IF  THIS  '  iTERRUPT  IS  OETECTED  BY  THE  SYSTEM,  THE 
0 1  SPLAY  WILL  BE  TERMINATED.  LIKE  THE  OVERALL  COMMANO 
STRUCTURE  ONLY  THE  FIRST  LETTER  OF  KEY  WORDS  ARE  EXAMINED. 
S*l  ANO  S  ARE  DIFFERENT  BECAUSE  ThE  FORMER  IS  A  KEYWORD 
(SIGNALLED  BY  THE  EQUAL  SIGN)  ANO  THE  LATTER  IS  A  POSITIONAL 
PARAMETER.  FINALLY,  TO  TERMINATE  THE  COMMANO  SCANNER,  ENTER 
A  SEMI-COLON  (;),  THIS  IS  PARTICULARLY  USEFUL  FOR  2260'S 
WITH  EXTRANEOUS  OATA  ON  THE  SCREEN. 


COMMAND  STRUCTURE*  JANUARY  1,  1969 
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FOR  THE  EDITING  COMMANDS*  EACH  RECORD  IN  THE  OATA  SET 
MUST  CONSIST  OF  A  SIX  CHARACTER  KEY  FOLLOWED  8Y  72 
CHARACTERS  OF  INFORMATION  SUCH  AS  FORTRAN  STATEMENTS  OR 
OATA.  UTILITY  PROGRAMS  WILL  BE  AVAILABLE  TO  READ  A  CARO  DECK 
INTO  A  DATA  SET  OR  VICE  VERSA.  IN  THAT  CaSE*  IN  READING*  THE 
FIRST  72  COLUMNS  WILL  BE  USED  AS  OATA,  AND  THE  LAST  6 
COLUMNS  AS  KEY*  AND  ON  PUNCHING  THE  SAME  FORMAT  WILL  BE 
USED. 


DELETE  RECORD  KEY 

DELETE  FIRST  KEY,  LAST  KEY 

DELETE 

in  six  char*.;ter  xey 

FOLLOWED  3Y  72 
CHARACTER  RECORD 


DELETE  THE  DESIGNATED  RECORD. 

DELETE  RECORDS  FROM  THE  FIRST 
KEY  TO  THE  LAST  KEY*  INCLUSIVE. 

DELETE  THE  LAST  RECORO 
ACCESSED.  E.G.  THE  LAST  RECORO 
DISPLAYED. 

ENTER  THIS  RECORO  IN  THE  DATA 
SET: 

a )  if  there  are  no  other 

RECORDS  WITH  THIS  KEY,  AS  A  NEW 
RECORD.  OR, 

B)  IF  ONE  EXISTS  WITH  THIS 
KEY,  AS  A  REPLACEMENT. 

IN  OPOER  TO  LIMIT  THE  ENTRY  TO 
NO  MORE  THAN  80  CHARACTERS, 
THIS  COMMAND  HAS  A  DIFFERENT 
FORMAT  FROM  OTHERS: 

l)  THE  TWO  LETTER  COMMAND 
"IN" 

21  A  KEY 

3 1  72  CHARACTERS  OF  TEXT 

NOTE:  THE  KEY  IS  A  STRING  OF 
ONE  TO  SIX  CHARACTERS.  THE  KEY 
WILL  BE  RIGHT-JUSTIFIED  IF  THE 
KEV  IS  LESS  THAN  SIX  CHARACTERS 
(LEADING  BLANKS  ARE  INSERTED 
INTO  THE  KEY  TO  MAKE  IT  SIX 
CHARACTERS).  THE  NEXT  CHARACTER 
AFTER  THE  FIRST  BLANK  STARTS 
THE  TEXT.  IF  THE  KEY  IS  OF  6 
CHARACTERS  THEN  THERE  MUST  BE 
NO  INTERVENING  BLANKS  BETWEEN 
"IN"  AND  THE  KEY,  AND  BETWEEN 
THE  KEY  AND  THE  TEXT. 
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THE  FOLLOWING  COMMAND  ALLOWS  THE  USER  TO  ENTER  INSERT 
NODE,  INSERT  MODE  TAKES  ANY  INPUT  WITHOUT  SCANNING  FOR  UHTSS 
COMMANDS  AND  INSERTS  THESE  RECORDS  ACCORDING  TO  THE  KEY 
GENERATION  FUNCTION.  THE  NORMAL  MODE  OF  TERMINATION  IS  AN 
ENCOUNTER  WITH  THE  SENTINEL. 

INSERT  FIRST  KEY,  ENTER  THE  FOLLOWING  RECORDS 

INCREMENT,  INTO  THE  OATA  SET  AUTOMATICALLY 

SENTINEL  GENERATING  THE  KEYS.  THIS 

PROCESS  HILL  STOP  WHEN  THE 
SENTINEL  IS  ENCOUNTERED. 


THE  "FIRST  KEY"  IS  A  NUMERIC 
STRING  (ONLY  0  TO  9  ARE 
ALLOWED). 

THE  NEXT  RECORD  WILL  HAVE  A  KtY 
WHICH  IS  THE  PREVIOUS  KEY  PLUS 
THE  "INCREMENT". 

THE  "SENTINEL"  IS  A  STRING  OF 
UP  TO  6  CHARACTERS.  THE  DEFAULT 

STRING  IS  'STOP _ Lx  THE 

FUNCTION  OF  THE  SENTINEL  IS  TO 
TERMINATE  THIS  MODE  OF 
INSERTION.  THE  FIRST  8 
CHARACTERS  OF  THE  RECORD  ARE 
EXAMINED  BEFORE  IT  IS  INSERTED. 
IF  THE  SENTINEL  STRING  IS 
ENCOUNTERED,  THE  PROCESS  STOPS. 

INSERT  BASIC.  THE  STRING  'BASIC'  MUST  APPEAR 

SENTINEL  TO  ENTER  THE  INPUT  BASIC  MODE. 

IN  THIS  MODE  THE  BASIC 
STATEMENT  LABEL  BECOMES  THE  KEY 
OF  THE  CARD.  THE  SENTINEL 
STRING  IS  AS  THE  PREVIOUS 
INSERT  COMMAND. 

NOTE  THE  BASIC  LABEL  MUST  OCCUR 
WITHIN  THE  FIRST  8  COLUMNS.  THE 
FIRST  BLANK  TERMINATES  THE  SCAN 
OF  THE  LABEL.  THE  NEXT 
CHARACTER  STARTS  THE  TEXT 
STATEMENT.  IF  THERE  IS  NO  KEY 
WITHIN  THE  FIRST  8  COLUMNS,  THE 
INSERT  MODE  IS  TERMINATED. 
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l&TeE&AL  CfiftflAftflS 

THE  FOLLOW  ing  commands  enable  special  services  for 

PROGRAMS  EXECUTING  IN  THE  UsER  AREA. 


LINK  DATA  SET  SELECTS  THE  DATA  SE?  AND 

TRANSFERS  CONTROL  INFORMATION 
TO  THE  USER*  S  SUFFER. 

LOAD  INDEX  READS  IN  THE  LOGICAL  TRACK  OF 

THE  "LINKED*  DATA  SET 
CORRESPONDING  TO  THE  INDEX 
VALUE.  THE  AREA  MUST  HAVE  ITS 
ADDRESS  IN  AREALOC  AND  SE  3536 
BYTES. 

DAOL  KEY  WRITES  A  LOGICAL  TRACK  WITH  THE 

CORRESPONDING  KEY.  THE  AREA 
MUST  HAVE  ITS  ADDRESS  IN 
AREALOC  AND  SE  3536  BYTES. 

THE  FOLLOWING  COMMANDS  ARE  A  RESULT  OF  IMPROVEMENTS  TO 

THE  DESIGN  EXTENDING  THE  FLEXIBILITY  OF  THE  SYSTEM. 


ALLOCATE  ALLOCATES  A  DATA  SET  NGOE  TO  A 

TERMINAL*  PROVIDING  THE  USER 
ACCESS  TO  MORE  THAN  ONE  DATA 
SET.  (NOT  ISSUED  AS  A  COMMAND). 

FREE  FREE  ALL  DATA  SET  NODES  EXCEPT 

THE  LAST  ONE.  (SINCE  (T  IS 
PERMANENTLY  ASSIGNED  TO  THE 
TERMINAL). 

REMOVE  REMOVE  A  TERMINAL  REQUEST  FROM 

MY  QUEUE  PROPERLY.  (RESULT  OF 
2260  IMPROVEMENTS). 
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DURING  EXECUTION  A  PROGRAM  MAY  REFERENCE  UP  TO  SEVEN 
DIFFERENT  DATA  SETS.  SEQUENTIAL,  60  BYTE  RECORD  I/O  IS 
ACCOMPLISHED  BY  USING  INPUTU).  OUTPUTlll,  INPUT  1 2 1 , 
OUTPUT  12).  DIRECT  ACCESS,  3000  BYTE  RECORD  I/O  IS 
ACCOMPLISHED  BY  USING  FILEUI,  FILE(2I  OR  FILEI3J.  DEFAULT 
DATA  SET  ASSIGNMENTS  ARE  PROVIOED  TO  SATISFY  NORMAL 

EXECUTION  CONDITIONS.  THEY  ARE  AS  FOLLOWS: 

EILE  QLEAULI 

OUTPUTlll  TERMINAL 

INPUT! 2 )  MOST  RECENTLY  SELECTED  DATA  SET 


BASIC  USES  INPUT ( 2 1  AS  THE  SOURCE  OF  THE  PROGRAM  TO  BE 
COMPILED.  CONSEQUENTLY,  THE  MOST  RECENTLY  SELECTED  DATA  SET 
PRIOR  TO  EXECUTING  BASIC  WILL  BE  AUTOMATICALLY  SEcECTEO  FOR 
COMPILATION.  THE  FIRST  TIME  AN  UNSPECIFIED  FILE  IS 
REFERENCED  FOR  AN  I/O  OPERATION,  THE  USER  IS  REQUESTED  TO 
DEFINE  THE  DATA  SET  BY  THE  MESSAGE 

SPEC- FY  OATA  SET  FOR  XXX. 

WHERE  XXX  IS  THE  REFERENCED  FILE.  TO  SPECIFY  THE  DATA  SET, 
TYPE  IN  THE  OATA  SET  NAME  ANO  PRESS  "ENTER".  THE  DATA  SET 
SPECIFIED  WILL  BE  SELECTEO  AND  USED  FOR  ALL  SUBSEQUENT 
OPERATIONS  ON  THAT  FILE.  TO  SPECIFY  1  HE  TERMINAL  AS  THE  DATA 
SET  FOR  ANY  FILE,  TYPE  IN  "//*  AND  PRESS  "ENTER".  AT  THE 
TERMINATION  OF  EXECUTION,  ALL  REFERENCED  DATA  SET  WILL  BE 
DESELECTED  AND  KEPT. 

TO  PREVENT  DEFAULT  ASSIGNMENTS,  TYPE  IN  "U"  AFTER  THE 
PROGRAM  NAME  TO  BE  EXECUTED;  SEPARATED  FROM  THE  PROGRAM  NAME 
BY  BLANKS  OR  A  COMMA. 
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THE  UHTSS/2  LIBRARY  STRUCTURE  ALLOWS  VARIOUS  TYPES  OF 
DATA  SETS  INCLUDING  PARTITIONED  DATA  SETS*  SEQUENTIAL  OA*A 
SETS  ANO  DIRECT  ACCESS  DATA  SETS.  EACH  OF  THESE  OATA  SETS 
MAY  CONTAIN  SEVERAL  USER  LIBRARIES  OR  THERE  MAY  BE  A  ONE  TO 
ONE  CORRESPONDENCE.  THE  ALLOCATION  OF  THESE  DATA  SETS  IS  A 
FUNCTION  OF  THE  UHTSS/2  MANAGEMENT. 

PUBLIC  LIBRARIES  ARE  OATA  SETS  THAT  ARE  MAINTAINED  BY 
THE  UHTSS/2  SYSTEM  AND  ARE  AVAILABLE  TO  A  LARGE  NUMBER  OF 
USERS  WITH  RELATIVE  SECURITY.  PRIVATE  LIBRARIES  ARE  DATA 
SETS  MAINTAINED  BY  THE  USERS  THEMSELVES  ANO  ARE  ALLOCATED  IN 
COOPERATION  WITH  THE  UHTSS/2  GROUP.  THE  SECURITY  OF  THESE 
DATA  SETS  IS  USER  OEFINEO*  (EITHER  USING  THE  SYSTEM  SCHEME 
OR  PROVIDING  THEIR  OWN  PASSWORD  PROCESSOR).  GARBAGE 
COLLECTION  ON  PRIVATE  LIBRARIES  IS  A  RESPONSIBILITY  OF  THE 
USER*  WHILE  GARBAGE  COLLECTION  ON  PUBLIC  LIBRARIES  IS  A 
RESPONSIBILITY  OF  UHTSS/2.  USERS  WITH  PRIVATE  LIBRARIES  MAY 
USE  OPERATING  SYSTEMS  FUNCTIONS  TO  MAINTAIN  AND  UPDATE  THEIR 
FILES  IF  THESE  SYSTEMS  FUNCTIONS  ARE  CAPABLE  OF  SUCH 
MAINTENANCE.  UHTSS/2  IS  NOT  REQUIRED  TO  MAINTAIN 
COMPATIBILITY  WITH  ANY  PRIVATE  FILES*  HOWEVER  THOSE  FILES 
THAT  ARE  CURRENTLY  UHTSS/2  COMPATIBLE  WILL  BE  COMPATIBLE 
WITH  FUTURE  VERSIONS  OF  UHTSS/2. 

each  user  library  may  have  associated  programmer's 

LIBRARIES.  THE  PROGRAMMER'S  LIBRARIES  MAY  CONSIST  OF  MANY 
DATA  SETS  EACH  OF  WHICH  MAY  CONTAIN  MORE  THAN  ONE  MODULE. 
THE  USUAL  CASE  IS  CME  MOOULE  PER  OATA  SET  PER  PROGRAMMER 
LIBRARY.  EACH  MOOULE  MAY  HAVE  MORE  THAN  ONE  MEMBER*  THIS  IS 
THE  CASE  FOR  A  MODULE  THAT  IS  A  POS. 
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********* 

♦UHTSS/2* 

♦LIBRARY* 

********* 


****************** ************ ************* 


********* 


********* 


♦PUBLIC  * 

********* 

* 

************ ******* ******** 


* 

* 

♦  TS  ♦ 

♦LIBRARY  ♦ 

********** 


* 

* 

********** 
♦USER  1  ♦ 

♦LIBRARY  ♦ 
********** 


* 

* 

********** 

♦USER  N  ♦ 
♦LIBRARY  * 

********** 


♦PRIVATE* 

********* 

* 

*************************** 

♦  ♦  * 

*  *  * 

**********  **********  ********** 


♦JOB  NO  1+ 
♦LIBRARY  ♦ 
********** 


♦JOB  NO  2* 
♦LIBRARY  ♦ 

********** 


•JOB  NO  N* 
♦LIBRARY  ♦ 
********** 


* 

* 

*************************** 

*«•****■ 

* 

* 

* 

* 

* 

* 

* 

* 

* 

• 

* 

* 

• 

********** 

********** 

•***•••*** 

********** 

********** 

********** 

♦  PRCGMP.  A* 

•PROGMR  8* 

♦PROGMR  Z* 

♦PROGMR  A* 

♦PROGMR  8* 

•PROGMR  Z* 

•LIBRARY  • 

•LIBRARY  ♦ 

•LIBRARY  • 

•LIBRARY  * 

•LIBRARY  * 

'LIBRARY  * 

********** 

********** 

* 

********** 

********** 

********** 

» 

• 

****••*«•••****•***•*•***** 

* 

*************************** 

* 

* 

* 

• 

• 

* 

* 

• 

* 

• 

* 

* 

********** 

******•»•• 

********** 

********** 

********** 

********** 

•SEQUEN-  ♦ 

•PARTI-  ♦ 

•DIRECT  * 

♦PARTI-  * 

•DIRECT  * 

•SEQUEN-  * 

•TIAL  • 

•TIONEO  * 

♦ACCESS  * 

♦TIONEO  * 

•ACCESS  * 

•TIAL  * 

•OATA  SET* 

•OATA  SET* 

♦DATA  SET* 

♦DATA  SET* 

•DATA  SET* 

•OATA  SET* 

• 

• 

•****•*••• 

********** 

* 

* 

• 

* 

******* 

* 

• 

• 

******* 

* 

* 

• 

• 

• 

• 

• 

********** 

•MODULE  l* 

•MODULE  2* 

•MODULE  M* 

•MODULE  1* 

•MLOUlE  2* 

•MODULE  M* 

• 

* 

********** 

* 

• 

********** 

* 

* 

********** 

♦MEMBER  A* 


* 

* 


♦MEMBER  B* 


* 


♦MEMBER  2* 


* 

* 


♦MEMBER  A* 


* 

* 

********** 

•member  a* 


* 

* 


•MEMBER  Z* 


V 


( 
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THE  DIRECTORY  IS  A  TABLE  OF  CONTENTS  OF  ALL  MODULES 
WITHIN  THE  PUBLIC  LIBRARY  OR  INDICATORS  TO  THESE  MODULES 
PROVIDING  SUCH  INFORMATION.  THIS  FACILITY  IS  REQUIRED  FOR 
USERS  SINCE  THEY  DC  NOT  HAVE  EASY  ACCESS  TO  THE  LIBRARIES  IN 
GENERAL.  USERS  MUST  BE  ABLE  TO  HAVE  ALL  OATA  SETS  ASSOCIATED 
TO  THEIR  ACCOUNTS  LISTED  YET  LOCKING  OUT  THOSE  WHO  DO  NOT 
HAVE  THE  SAME  ACCOUNT.  THE  USER  IS  REQUIRED  TO  KEEP  TRACK  OF 
HIS  PRIVATE  LIBRARY.  UHTSS/2  WILL  NOT  SEARCH  PRIVATE 
LIBRARIES  IN  ORDER  TO  MAINTAIN  THEIR  INTEGRITY. 

THE  TWO  PUBLIC  UHTSS/2  SYSTEMS  LIBRARIES  ARE  UhTSS/? 
LQADLIB.  A  POS  WHICH  CONTAINS  ALL  UHTSS/2  MONITOR  ROUTINES 
AND  USER'S  PUBLIC  LOAD  MCOULES,  AND  UHTSS/?  USFRIIB.  A 
DIRECT  ACCESS  OATA  SET  WHICH  CONTAINS  USER  PROGRAMS  IN 
EITHER  SOURCE  OR  OBJECT  FORM  ANO  A  LIMITED  NUMBER  OF  USER 
OATA  FILES  IRESTRICTED  TO  SEQUENTIAL  CARD  IMAGE  DATA  THAT  IS 
NORMALLY  PASSED  THROUGH  THE  SYSIN  OATA  SET). 

UUISSZi_LflAflLia 

THE  UHTSS/2  LOAOLIB  IS  A  PARTITIONED  DATA  SET,  PDS, 
WITH  A  PRIMARY  ALLOCATION  OF  50  CYLINDERS.  ANY  USER  MAY 
ACCESS  THIS  LIBRARY  SINCE  THE  LINKEDIT  SYSLIB  DO  CARO  WILL 
POINT  TO  THIS  OATA  SET,  I.E.  THE  LIBRARY  WILL  BE 
CONCATENATED  TO  LOAD. SYSLIB.  THIS  LIBRARY  WILL  BE  READ-ONLY 
EXCEPT  UNDER  SPECIAL  CONOtTONS.  THE  SPECIAL  CONDITIONS  WILL 
BE  GOVERNED  BY  THE  UHTSS/2  MANAGEMENT  TO  EFFECTIVELY 
SUPERVISE  THE  LOAD  MOOULES  ANO  SCRUPULOUSLY  RECOVER  THE 
UPDATE  PGM  OPERATES  BY  EXAMINING  THE  MODULE  SPECIFIED  ANO 
THE  OPTIONS. 
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THE  UHTSS/2  USERLIB  IS  A  OIRECT  ACCESS  OS  OATA  SET  OF 
50  CYLINDERS.  ONLY  USERS  WHO  HAVE  THE  PROPER  PASSWORD  MAY 
ACCESS  THIS  LIBRARY.  LOCK-OUT  FEATURES  LIKE  READ-ONLY  TO  ANY 
JOB  NUMBER  OR  TO  NO  OTHER  JOB  NUMBER  OR  TO  NO  OTHER 
PROGRAMMER  NAME  HILL  BE  IMPLEMENTED.  ONE  PASSWORD  SCHEME  IS 
JOB  NUMBER  CONCATENATED  WITH  PROGRAMMER  NAME  CONCATENATED 
WITH  THE  MODULE  NAME.  ADDITIONAL  FLAGS  WILL  BE  SET  WITHIN 
THE  MODULE  TO  INDICATE  ITS  OTHER  LOCK-OUT  FEATURES.  THE 
ACTUAL  STRUCTURE  OF  THE  USERLIB  FOLLOWS: 

A  MODULE  IS  A  LOGICAL  RECORD. 

A  LOGICAL  RECORD  IS  ONE  OR  MORE  PHYSICAi  TRACKS  OF  AN 
IBM  2316  DISK  UNIT*  WHICH  HAS  A  DATA  TRANSFER  RATE  OF 
111  MS  PER  TRACK*  ASSUMING  THE  AVERAGE  SEEK  AND 
ROTATION  TIME.  A  PHYSICAL  TRACK  CONTAINS  7200  BYTES.  IF 
THE  LOGICAL  RECORD  CONTAINS  MORE  THAN  A  TRACK*  A  CHAIN 
POINTER  WILL  BE  SET. 

A  LOGICAL  RECORD  CONSISTS  OF  ONE  OR  MORE  LOGICAL 
MEMBERS.  A  LOGICAL  MEMBER  HAS  THREE  FLAGS,  THE  LANGUAGE 
FLAG,  THE  FORMAT  FLAG,  AND  THE  TYPE  FLAG.  THE  LANGUAGE 
FLAG  INDICATES  WHETHER  THE  MEMBER  IS  A  FORTRAN  PROGRAM 
OR  SOME  OTHER  HIGH-LEVEL  LANGUAGE.  THE  TYPE  pLAG 
INDICATES  WHETHER  THE  MEMBER  IS  SOURCE  DECK*  AN  OBJECT 
OECK,  OR  A  DATA  OECK.  THE  FORMAT  FLAG  INDICATES  FORMAT 
OF  THE  MEMBER,  WHICH  IS  EITHER  CARD  IMAGE.  PRESSOECK, 
OR  FREEFORM. 

CARD  IMAGE  IS  EXACTLY  AS  A  CARD  WOULD  APPEAR.  80  BYTES 
OF  EBCDIC  INFORMATION. 

PRESSOECK  IS  A  COMPRESSION  OF  AN  ACTUAL  CARD  WITH 
STRINGS  OF  THE  SAME  CHARACTER  COMPRESSED  INTO  3  BYTES 
OF  COOED  INFORMATION. 

FREEFORM  ALLOWS  HIGH-LEVEL  LANGUAGES  TO  BE  EXPRESSED  IN 
A  SIMPLE  SYNTAX.  THIS  FORMAT  ALLOWS  THE  USER  SOME 
INOEPENOENCE  OVER  HIS  TERMINAL  DEVICE  AND  FREES  HIM 
FROM  FIXED  FORM  WHERE  COLUMN  7  IS  NOT  READILY  VISIBLE. 
WHEN  A  PROGRAM  IN  FREEFORM  IS  PASSEO  TO  A  COMPILER, 
UHTSS  WILL  REFORMAT  THE  OATA  INTO  ACCEPTABLE  FORMAT, 
NAMELY  PROPER  COLUMNS  ANO  SO  FORTH.  THE  FREEFORM  SYNTAX 
IS  SPECIFIED  IN  BACKUS  NAUR  FORM.  NOTE  THAT  STRING  IS 
ASSUMED  TO  BE  THE  CORRECT  SEQUENCE  OF  CHARACTERS 
ALLOWEO  BY  THE  HIGH-LEVEL  LANGUAGE. 

<LA8EL>  <NULL>  I  <STRING>  I  <LABEl>: 

<COMMENT>  *  <STRING> 

<STATEMENT>  <STR!NG>  I  <COMM£NT> 

<SENTENCE>  :»  <LABEL>  <STATEMcNT>; 

<PROGRAM>  :»  <SENTENC£>  I  <PP.OGRAH>  <SENTENCE> 
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THE  FUNCTIONS  OF  THE  UPOATE  PROGRAM  ARE  INCLUDEO  IN  THE 
FOLLOWING  LIST: 

1.  INTERROGATE  THE  INPUT  OATA  SET  WHICH  MAY  BE  A  PDS  OR  AN 
ISAM  FILE. 

2.  POSITION  OATA  SET  AT  A  DESIREO  LINE  NUMBER  OR  CHARACTER 
STRING. 

3.  UTILIZE  THE  WORK  AREA  OATA  SET  TO  OPTIMIZE  THE  OTHER 
FUNCTIONS. 

4.  PROVIOE  RECOVERY  MECHANISMS  FOR  RETRIEVAL  OF  FILES 
AFTER  SYSABENO. 

5.  AOO  OR  DELETE  CHARACTER  STRINGS  WITHIN  THE  GIVEN  TEXT. 

6.  OUTPUT  TO  THE  USER  RESULTS  OF  INTERROGATION 
( HARDCOPY/O I  SPLAY I • 

7.  EDIT  TEXTS  BY  REPLACING  ONE  STRING  FOR  ANOTHER  STRING 
THROUGHOUT  THE  TEXT. 


ACCIDENTAL  DELETIONS  OF  MOOULES: 

IF  A  PROGRAM  10  IS  SPECIFIED,  UPDATE  PGM  ATTACHES 
IT  AND  WAITS  FOR  ITS  COMPLETION.  NOTE  THAT  THE  PROGRAM 
MUST  RESIDE  IN  THE  LIBRARY  SPECIFIED.  IF  NO  LIBRARY  IS 
SPECIFIED*  UHTSS/2  l GAOL  IB  IS  USED.  IF  NO  PRQGRAN  ID  IS 
SPECIFIEO,  THE  UPOATE  PGM  ATTACHES  A  MODULE  WHICH  WILL 
OPTIMIZE  THE  FUNCTIONS  BY  USING  THE  BEST  ACCESS  METHOD 
FOR  THE  GIVEN  INPUT  OATA  SET  AND  WORK  AREA. 
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SELECTIVE  LOADING  ALIGNS  THE  SOPHISTICATED  USER  TO  SAVE 
TIME  8Y  ELIMINATING  RECOMPILATIONS  ANO  SOFTWARE  GENERATION. 

SUPPOSE  USER  X  HAS  HIS  FORTRAN  PROGRAM  IN  SOURCE 
FORM.  THE  PROGRAM  CONSISTS  OF  MAIN  ROUTINE  AND  3 
SUBROUTINES*  SUBl*  SU82*  AND  SUB3.  NOTE  THAT  MAIN  CALLS 
SUBl  WHICH  CALLS  SUB2  WHICH  CALLS  SUB3  WHICH  CALLS 
MULREG.  HE  HAS  COMPILED  ALL  OF  THE  MEMBERS  OF  THE 
MODULE  ANO  SAVEO  THEM  IN  ANOTHER  MOOULE*  SAY  OBJTMOD. 
BUT  MULREG  HAS  BEEN  WRITTEN  ANO  DEBUGGED  BY  USER  Y  ANO 
MAS  INSERTED  INTO  THE  PUBLIC  LIBRARY.  ASSUME  THAT  SU82 
HAS  A  BUG  IN  IT  .  THE  PROBLEM  IS  HOW  DOES  USER  X 
CORRECT  SUB2  ANO  EXECUTE  THE  PROGRAM  AGAIN. 

THE  SOLUTION  IS  GIVEN  IN  A  PROTC-TYPE  OF  THE 
COMMAND  LANGUAGE.  NOTE  THAT  MULREG  IS  AUTOMATICALLY 
LINKEO  WITH  USER  X*S  PROGRAM. 

UPOATE  0 A 00. X. FORT MOD. SUB 2 

!  UPDATE  SEQUENCE  AS  REQUIRED. 

FORT  0400.X. FORTMOD.SUB2 

SAVE  0400.X. OBJTMOD. SUB2 

INCLUDE  04O0.X.OBJTMO0 
ENTRY  MAIN 

XEQ 


AN  EXTENSION  OF  THE  COMMANO  WILL  ALLOW  THE 

USER  ' 1  COMPILE*  LOAO*  ANO  GO  WITH  A  SINGLE 
INSTRUCTION.  SUPPOSE  USER  X  HAS  A  MOOULE  WITH  3 
MEMBERS.  THE  FIRST  MEMBER  IS  THE  FORTRAN  MAIN  PROGRAM 
IN  SOURCE  FORM.  THE  SECOND  MEMBER  IS  A  FORTRAN 
SUBROUTINE  IN  OBJECT  FORM.  AND  THE  THIRO  MEMBER  IS  DATA 
IN  CARO  IMAGE  FORMAT. 

THE  INSTRUCTION  XFO  MYMQO  IS  EQUIVALENT  TO  THE 

FOLLOWING  INSTRUCTIONS.  LET  THE  MODULE  NAME  BE  -MYrtOO* 
ANO  THE  MtMBERS  BE  •MAIN,*  "SUB**  ANO  •SYSIN."  NOTE 
, MAT  "SYSIN"  WOULD  BE  AUTOMATICALLY  INSERTEO  INTO  THE 
INPUT  STREAM. 

FORT  0400. X. MYMQO. MAIN 

INCLUOE  0400. X.MYMOO. SUB 
ENTRY  MAIN 

XEQ 
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SWITCH  NAME  IS  A  TECHNIQUE  THAT  ALLOWS  THE  RECOVERY  OF 
MOOULES  THAT  HAVE  BEEN  OELETED.  WHEN  AN  OLO  MEMBER  OF  A 
MOOULE  IS  UPDATED*  ITS  NAME  IS  CHANGED  AND  IT  IS  NOT 
SCRATCHED.  THE  NEC  MEMBER  IS  INSERTEO  WITH  THE  PROPER  NAME. 
IN  THIS  MANNER*  THE  GARBAGE  COLLECTOR  MAY  RETRIEVE  MODULES 
THAT  HAVE  BEEN  ACCIDENTLY  LOST.  A  PROBLEM  IS  THAT  AN  U  USUAL 
AMOUNT  OF  DEAD  SPACE  IS  CREATED*  SO  SHOULD  TKC  UHTSS 
MANAGEMENT  ALWAYS  SCRATCH  OLO  MOOULES  AT  THE  ENO  Or  a  STEP* 
OR  SHOULO  IT  ALWAYS  SAVE  MODULES  UNTIL  THE  ENO  OF  THE  JOB. 


PASSWORD  SECURITY  ALLOWS  THE  USER  LOCK-OUT  OF  USERS  WHO 
DO  NOT  SHARE  THE  SAME  JOB  NUMBER  OR  OTHER  ESOTERIC 
CONVENTIONS.  THE  PRQPOSEO  TECHNIQUE  IS  A  METHOD  OF  r A  '-'SWORD 
SECURITY*  WHERE  THE  PASSVORO  IS  THE  CONCATENATED  STRING  OF 
CHARACTERS  INCLUDING  THE  JOB  NUMBER*  THE  PROGRAMMER'S  NAME* 
ANO  THE  MODULE  NAME.  THE  NEXT  LEVEL  OF  PROTECTION  IS  TO 
INCLUDE  A  MGDULE  PASSWORD  ANO  FINALLY  THE  MEMBER  PASSWORD. 
BUT  THERE  IS  STILL  A  NEED  FOR  THE  ABILITY  TO  ALLOW  READ-ONLY 
TO  ALL  USERS  WHO  KNOW  THE  PASSWQRO  AND  FINALLY  TO  ONLY  USERS 
WHO  HAVE  THE  SAME  JOB  NUMBER  ANO  PROGRAMMER  NAME  AND  THE 
PASSWORO.  IN  THE  HIERARCHIC  STRUCTURE*  THERE  IS  A  SIMPLE 
ALGORITHM  TO  DETERMINE  THE  LOCK-OUT  MECHANISM*  NAMELY  AT 
EACH  LEVEL  OF  LIBRARY  STRUCTURING  PROVIDE  A  FLAG  TO  INDICATE 
ITS  RELATIVE  PROTECTION.  OTHER  TECHNIQUES  ARE  DEVELOPABLE* 
BUT  THE  PREVIOUS  METHOD  IS  THE  SIMPLEST. 

FOR  PRIVATE  LIBRARIES*  A  SIMPLE  MECHANISM  FOR  SECURITY 
IS  TO  SPECIFY  THE  OONANE  TO  BE  THE  SAME  NAME  OF  A  PASSWORD 
PROCESSOR,  A  LOAD  MOOULE  RESIOING  IN  UHTSS/2  LOAOLIB.  WHEN 
THE  USER  SPECIFIES  THIS  OONANE  FOR  THE  UHTSS/2  ALLOCATOR, 
THE  ALLOCATOR  WILL  USE  THAT  OONANE  AS  ThE  ENTRY  POINT  NAME 
AND  ATTACH  IT  FROM  LOAOLIB.  THE  USER  PASSWORD  PROCESSOR  CAN 
THEN  INTERROGATE  THE  USER  ANO  RETURN  HIS  STATUS.  HE  IS 
EITHER  ALLOWEO  TO  USE  THE  OATA  SET  ENTIRELY,  OR  ONLY  SOME 
MEMBERS,  OR  NOT  A?  ALL,  OR  THE  SYSTEM  SHOULO  INVESTIGATE 
IMMEDIATELY  THAT  SOMEONE  I  -  ATTEMPTING  TO  BREAK  INTO  HIS 
LIBRARY. 

PASSWORD  EL  L1&  111  SHOULD  BfENEQRLEQ  AI  THE  ALLOCATlpN 

of.  .resqurlu,  jhuul auama, olluk  a&jL-AL.iiiE..M tializaiiqn 

Of  THE. JOB. _Ih£_USER. WOULD  NOT,  £N;OY  CONSTANT  QUERY  OF  HIS 
ABILITY  IQ  USE  THE  RESOURCES. 
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AMIil 


USER  PROGRAMS  EXIST  IN  ONE  OF  THREE  FORMS: 

u  SOURCE  FORM  IS  THE  CARD- IMAGE  INPUT  TO  HIGH-LEVEL 
LANGUAGES  SUCH  AS  FORTRAN  ANO  ASSEMBLER. 

2.  OBJECT  FORM  IS  THE  CARD- IMAGE  OUTPUT  OF  HIGH-LEVEL 
LANGUAGES*  I.E.  RELOCATABLE  BINARY  FORM. 

3.  LOAD  FORM  IS  THE  OUTPUT  OF  THE  LINKAGE  EDITOR*  I.E. 
A  COMPACTED  RELOCATABLE  BINARY  FORM. 


OBJECT  OR  LOAD  MODULES  (PROGRAMS  IN  OBJECT  OR  LOAD 
FQRM)  ARE  USED  TO  AVOID  RECOMPILATION  ANO  ARE  GENERALLY 
DEBUGGED  ROUTINES.  THE  USE  OF  THESE  MODULES  WILL  DECREASE 
THE  LINKAGE  EOITOR'S  TIME.  LOAD  MODUcES  ARE  THE  HOST  DESIRED 
FORM  BECAUSE  THEY  ARE  LINKED  FASTER*  BUT  SUFFER  THE 
DISADVANTAGE  OF  REQUIRING  DIRECT  ACCESS  ALLOCATION. 
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flsttaimfltt-flfr  .os/Hvi  miua&MiAiiflK 

UHTSS  USERL1B  IS  A  COLLECTION  OF  USER  LIBRARIES  C  DATA 
SETS)  FOR  THE  UHTSS  PROJECT.  ITS  ORGANIZATION  IS  DIRECT, 
PARTITIONED,  ANO  INDEXED  SEQUENTIAL  TO  MINIMIZE  DISK  SEEK 
TIME,  TO  REDUCE  DISK  READ /WRITES,  AND  TO  EFFICIENTLY  UTILIZE 
DISK  SPACE.  IT  IS  OIRECT  BECAUSE  ANY  MEMBER  OF  ANY  USER 
LIBRARY  IS  ACCESSIBLE  GIVEN  ITS  ADDRESS.  IT  IS  PARTITIONED 
BECAUSE  LIBRARIES  ARE  OSVIOED  LQGICALLLY  WITHIN  THE  USERLIB. 
FINALLY,  IT  IS  INOEXEQ  SEQUENTIAL  BECAUSE  ANY  USER  MEMBER  IS 
SEQUENTIALLY  ORGANIZED  WITH  A  KEY. 

THE  PHYSICAL  ORGANIZATION  OF  THE  UHTSS  USERUB  IS 
NEITHER  LIMITED  TO  ONLY  A  SET  OF  CONTIGUOUS  CYLINDERS  NOR 
LIMITED  TO  A  SINGLE  DISK  PACK.  UHTSS  USERLIB  IS  ORGANIZED 
AND  SO  STRUCTURED  THAT  IF  IT  RESIDES  ON  A  OEOICATEO  DISK 
PACK,  ARM  CONTENTION  AND  SEEK  TIMES  WILL  BE  KEPT  AT  A 
MINIMUM.  THE  PRESENT  IMPLEMENTATION  OF  USERLIB  IS  TO  MAKE  IT 
AN  OS  DIRECT  DATA  SET  WITH  HALF  TRACK  BLOCKS.  EACH  HALF 
TRACK  BLOCK  IS  CALLED  A  LOGICAL  TRACK,  LT,  ANO  IS 
CONSECUTIVELY  NUMBERED.  THE  NUMBER  OF  LOGICAL  TRACKS  IS 
FORTY  TIMES  THE  NUMBER  OF  ALLOCATED  CYLINDERS*  NOTE  THAT 
ONLY  THE  PRIMARY  EXTENT  IS  CONSIDERED.  THE  DISK  ADDRESS  OF 
EACH  LOGICAL  TRACK  IS  COMPUTABLE  FROM  THE  LOGICAL  TRACK 
NUMBER,  LT#  ,  NHL  ;E  CYLI NDER«LT#/40,  TRACK»MQD(LT# , 40 ) /Z,  AND 
RECORD»MOOILT#,2m.  NOTE?  HEREAFTER,  DATA  SETS  WILL  REFER 
TO  USER  DATA  SETS,  NOT  THE  USERLIB  DATA  SET. 

THE  MAJOR  REASON  FOR  HALF  TRACK  RECOROS  IS  THAT  THE 
UPDATE  PROCESS  WILL  BE  COMPLETED  IN  1  1/2  REVOLUTIONS;  1/2 
REVOLUTION  TO  READ  IT  IN,  1/2  REVOLUTION  TO  UPOATE  IN  CORE, 
AND  1/2  REVOLUTION  TO  WRITE  IT  OUT  AGAIN.  THIS  IS  ABOUT  THE 
FASTEST  METHOD  OF  UPDATING  THE  DISK  GIVEN  A  SINGLE  BUFFER. 
NOTE  TOO,  THAT  THE  HIGH  FREQUENCY  OF  DISK  ACTIVITY  REQUIRES 
INFORMATION  TO  9E  WRITTEN  IMMEDIATELY  IN  ORDER  TO  INSURE 
RELIABILITY. 

TIMING  CONSIDERATIONS  ON  THE  IBM  2314: 

1)  DATA  TRANSFER  OF  3620  BYTES  IS  11. 5  MS. 

2)  MINIMUM  SEEK  TIME  TO  AN  ADJACENT  CYLINDER  IS  25  MS. 

3)  AVERAGE  ROTATIONAL  DELAY  IS  12.6  MS. 


) 


4)  OESIGN  AVERAGE  SEEK  TIME  IS  37.6  MS 


»  # 
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QESCiLLP Xlfiii  Q t  UHTSS  USERL1B 

THE  LOGICAL  ORGANIZATION  OF  THE  CATA  SET  CONSISTS  OF  A 
DIRECTORY  ANO  USER  MEMBERS  I  OAT  A  SETS).  THE  DIRECTORY 
CONSISTS  OF  A  DIRECTORY  TABLE  OF  CONTENTS,  OTCC,  AND  SEVERAL 
DIRECTORY  PAGES,  DP.  THE  KEY  TO  ANY  USER  OATA  SET  IS  ITS  JOB 
NUMBER,  ACCOUNT  NUMBER,  AND  OATA  SET  NAME,  OSNAME.  THE  OTOC 
PROVIDES  THE  OP  NUMBER  GIVEN  THE  KEY  CONSISTING  OF  THE  JOB 
ANC  ACCOUNT  NUMBERS.  THE  OP  PROVIDES  THE  LT#  OF  THE  DATA  SET 
GIVEN  THE  KEY  CONSISTING  OF  THE  JOB  ANO  ACCOUNT  NUMBERS  AND 
THE  OATA  SET  NAME.  A  OATA  SET  CONSISTS  OF  A  PRIMARY  LOGICAL 
TRACK  AND  PERHAPS  SEVERAL  SECONDARY  LOGICAL  TRACKS.  THE 
PRIMARY  LT  CONTAINS  A  LIST  OF  POINTERS  TO  THE  OTHER 
SECONDARY  LTS.  THE  SECONDARY  LTS  ARE  NOT  CHAINED  IN  OROER  TO 
MINIMIZE  THE  UPDATING  PROCESS.  WITHIN  THE  PRIMARY  LT  AND  THE 
SECONDARY  LTS,  THE  INDIVIDUAL  RECORDS  (CARD  IMAGES)  ARE 
SEQUENTIAL  WITH  RESPECT  TO  THEIR  ASSOCIATED  KEYS. 

THE  TREE  STRUCTURE  OF  "USERLIB"  IS  INDEXED  SEQUENTIAL 
WITH  3  LEVELS  OF  DIRECTORIES.  THE  FIRST  DIRECTORY,  WHICH  IS 
CORE  RESIDENT,  PARTITIONS  THE  DATA  SETS  BY  JOB/ACCOUNT 
NUMBER  INTO  PAGES.  THE  SECOND  DIRECTORY,  RESIOING  ON  DISK, 
PARTITIONS  BY  DATA  SET  NAME  BY  JOB/ACCOUNT  NUMBER  INTO  THE 
ACTUAL  OATA  SETS.  THE  LAST  DIRECTORY,  CONTAINED  WITHIN  THE 
DATA  SET  ITSELF  ON  OISK,  PARTITIONS  THE  DATA  SET  INTO 
LOGICAL  TRACKS. 

THUS  TO  RETRIEVE  A  BLOCK  OF  INFORMATION  FROM  ANY  OATA 
SET  INVOLVES:  FIRST,  AN  IN-CORE  SEARCH  OF  THE  DTOCi  NEXT,  A 
DISK  READ  AND  SEARCH  OF  THE  DIRECTORY  PAGE,  A  DISK  READ  ANO 
SEARCH  OF  THE  PRIMARY  TRACK;  ANO  FINALLY,  A  DISK  READ  OF  THE 
TRACK  THAT  HAS  THE  BLOCK  OF  INFORMATION.  NOTE  THAT  IF  THE 
TRACK  THAT  HAS  THE  DESIRED  BLOCK  OF  INFORMATION  IS  THE 
PRIMARY  TRACK,  THE  TOTAL  NUMBER  OF  DISK  READS  IS  TWO. 
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DESCRIPTION  Q£_  DIRECTORY  TABLE  QF  CONTENTS.  DTQC 

THE  DTuC  PARTITIONS  THE  USER  OATA  SETS  SQ  THAT  THE 
DIRECTORY  PAGES  ARE  EVENLY  ALLOCATED.  USERS  OF  THE  SAKE  JOB 
NUMBER  WITH  MANY  OATA  SETS  ARE  ALLOCATED  AN  ENTIRE  DIRECTORY 
PAGE.  THE  PARTITIONING  ALGORITHM  IS  A  MANAGEMENT  OECISION 
SCHEME. 

THE  DTOC  CONTROLS  THE  USE  OF  THE  FREE  LOGICAL  TRACKS* 
FLT,  TO  EFFICIENTLY  ALLOCATE  AND  GARBAGE  COLLECT.  EACH 
ALLOCATION/COLLECTION  CYCLE  UPDATES  THE  DTOC  ANO  THUS 
REQUIRES  THE  REWRITING  OF  THE  NEW  OTQC  ONTO  OISK  TO  INSURE 
SYSTEMS  RELIABILITY. 

EACH  CYLINDER  HAS  A  VERSION  OF  THE  DTOC  AS  ITS  FIRST 
RECORD  OF  ‘SHE  LAST  TRACK.  BEFORE  EACH  REWRITE*  THE  OTOC  USE 
COUNT  FIELD  IS  INCREMENTED  BY  ONE.  THE  UPOATED  DTOC  IS  THEN 
REWRITTEN  ONTO  THE  CYLINOER  WHERE  THE  ARM  IS  TO  BE 
POSITIONED  FOR  THE  NEXT  READ/ WR ITE.  THE  DTOC  WITH  THE 
HIGHEST  USE  COUNT  IS  THE  CURRENT  DT( . .  THE  CURRENT  DTOC  IS 
MODE  CORE-RESIDENT  DURING  THE  UHTSS  INITIALIZATION  PROCESS. 

THE  CREATION  OF  A  OATA  SET  WILL  CAUSE  AN  ALLOCATION  OF 
ONLY  THE  PRIMARY  LT.  SECONDARY  LTS  ARE  ALLOCATED  ONLY  WHEN 
THEY  ARE  REQUESTED.  IN  THIS  MANNER  THE  USERLIB  WILL  MINIMIZE 
THE  DEAD  SPACE/GAS  IN  EACH  USER'S  DATA  SET. 

THE  DIRECTORY  PAGE  BLOCK  IS  A  DESCRIPTOR  RECORD  WHICH 
CONTAINS  A  POINTER  TO  THE  PROPER  PAGE  TRACK.  THIS  POINTER  IS 
THE  PAGE  LOGICAL  TRACK  NUMBER. 

AT  THE  PRESENT  TIME  THE  OTOCS  REQUIRE  2.5*  OF  THE  OATA 
SET  CAPACITY. 
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LENGTH  OF  SELECT/LOCK  KEY  (*0) 
DIRECTORY  PAGE  BLOCK  1 
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fli&BiPIlQtt  ,Qf  QlRL£lQfit..PAG£i,.CB 

THE  OP  CONTAINS  A  SEQUENTIAL  LIST  OF  USER  OATA  SETS 
OROEREC  BY  JC8  NUMBER «  ACCOUNT  NUMBER*  AND  DSNAME.  THE  LIST 
HAS  THE  LT#  OF  THE  PRIMARY  LT  AND  ACCOUNTING/MAINTENANCE 
INFORMATION.  THE  "LAST  USED"  OATE  AND  USE  COUNT  FIELD 
REFLECTS  THE  FREQUENCY  OF  USE  OF  THE  OATA  SET.  THE  USER  WILL 
BE  CHARGED  ACCORDINGLY  AND  THE  UHTSS  MANAGEMENT  CAN 
DETERMINE  WHETHER  OR  NOT  THE  DATA  SET  IS  TO  BE  MOVED  TO  THE 
LEAST  ACCESSED  REGION  OF  USERUB  OR  EVEN  ONTO  OEAO  STORAGE 
(TAPE)  . 

THE  PHYSICAL  LOCATION  OF  THE  OP  IS  THE  CENTER  CYLINDER 
OF  USERLIB.  THE  CENTRAL  CYLINDER  STRATEGY  MINIMIZES  THE  SEEK 
TIME  FOR  USER  OATA  SETS  SINCE  THE  OP  IS  ALWAYS  ACCESSED 
FIRST.  THUS  THE  AVERAGE  SEEK  TIME  BECOMES  37.5  MS  FOR  A 
OEDICATED  PACK. 

THE  SELECTION  OF  A  USER  OATA  SET  REQUIRES  ONLY  ONE  DISK 
READ.  FROM  THE  CORE  RESIDENT  DTOC*  THE  LT  OF  THE  OP 
ASSOCIATED  WITH  THE  DSNAME  IS  OBTAINED.  THAT  LOGICAL  TRACK 
IS  THEN  READ.  FROM  THE  OP*  THE  LT#  OF  THE  PRIMARY  LT  OF  THE 
OATA  SET  IS  QBTAINEO.  NOTE  THAT  THE  DATA  SET  KEY  IS  THE 
JOB/ACCOUNT  NUMBER  CONCATENATED  WITH  THE  DATA  SET  NAME. 

THE  DATA  SET  OIRECTQRY  BLOCK  IS  A  DESCRIPTOR  RECORD 
WHICH  HAS  A  POINTER  TO  THE  PRIMARY  TRACK  OF  THE  DATA  SET. 
THE  OATES  IN  THE  RECORD  ALLOW  THE  MANAGEMENT  ROUTINES  TO 
DETERMINE  THE  STATUS  OF  THE  DATA  SET. 

AT  THE  PRESENT  TIME,  THE  DIRECTORY  PAGES  CONSIST  OF 
0.91  OF  THE  DATA  SET  CAPACITY*  ABOUT  I  CYLINDER  OUT  OF  101 
CYLINDERS. 

THE  ALLOCATION  OF  JOB/ ACCOUNTS  TO  PAGE  TRACKS  OEPENDS 
UPON  THE  FREQUENCY  USE  BY  THOSE  USERS.  AT  THE  PRESENT  IT  IS 
ARBITRARILY  ASSIGNED.  AN  ALGORITHM  FOR  PAGE  OVERFLOW  MUST  BE 
DEVISEO.  ONE  POSSIBLE  STRATEGY  IS  TO  MAKE  OATA  SET  BLOCKS 
INTO  CARO  IMAGES  AND  USE  THE  TRACK  OVERFLOW  MECHANISM.  BUT 
THERE  ARE  PROBLEMS  IN  POSITIONING  THE  PAGE  TRACKS  NEAR  THE 
CENTRAL  CYLINOER.  THE  ASSOCIATED  DIRECTORY  PAGE  BLOCKS  WILL 
BE  USED  FOR  THE  OVERFLOW  ALGORITHM. 


; 

i 
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*  BLOCK  1 


BLOCK  2 


BLOCK  3 


BLOCK  4 


LT  BLOCK  . _ _ _ . 

I  I 
TEXT  INFO.  I  POINTER  TO  Tr*E  LOGICAL  TRACK  I 
KEY  INFO.  I  KEY  OF  THE  LAST  CARO  IN  THAT  LT  1 


CARO  INAGE  . _ -  .  _ _ . 

I  i 

TEXT  1  NFC  *  J  ACTUAL  TEXT  | 

KEY  INFO.  I  KEY  FOR  THE  TEXT  | 


NUMBER  OF  WOROS  IN  BLOCK  1 
NUMBER  OF  WORDS  IN  BLOCK  2 
NUMBER  OF  WOROS  IN  BLOCK  3 
NUMBER  OF  WORDS  IN  BLOCK  4 
NUMBER  OF  WOROS  IN  FREE  AREA 


JOB/ACCOUNT  NUMBER  OF  LOGICAL  TRACK 
OATA  SET  NAME  OF  LOGICAL  TRACK 
USER*  S  ( PROGRAMMER*  S I  NAME 
USE  COUNT  OF  LOGICAL  TRACK  WRITES 
SELECT/LOCK  KEY  FOR  LOGICAL  TRACK 


NUMBER  OF  LOGICAL  TRACKS  IN  MODULE 
LENGTH  OF  LOGICAl  TRACK  TEXT 
LENGTH  OF  LOGICAL  TRACK  KEV 
LENGTH  OF  LT  SELECT/LOCK  KEY 
LOGICAL  TRACK  BLOCK  1 


LOGICAL  TRACK  BLOCK  N 


NUMBER  OF  CARO  IMAGES  IN  MCOULE 
LENGTH  OF  CARO  TEXT 
LENGTH  OF  CARO  IMAGE  KEV 
LENGTH  OF  CARO  IMAGE  LOCK  l-O) 
CARO  IMAGE  1 


CARO  IMAGE  M 


FREE  WORK  AREA  SPACE 
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Qfci£EigIlflh.O£-JiHT,SS  HAIA.5EI 

The  USER  OATA  SET  CONSISTS  OF  A  PRIMARY  LT  AND  PERHAPS 
SEVERAL  NON-CONSECUT I VE  SECONDARY  LTS.  THE  PRIMARY  LT  HAS  A 
LIST  OF  SECONOARY  LTS  THAT  IS  ORDERED  BY  THE  KEY  OF  THE  LAST 
RECORO  OF  THE  LT.  A  SEGMENT  OF  THIS  LIST  IS  RESIOENT  HI  THIN 
THE  ACTIVE  TERMINAL  TABLE  TO  MINIMIZE  THE  READING  OF  THE 
PRIMARY  LT  FOR  THE  LT  ASSOCIATED  WITH  THE  UPDATE  KEY.  EACH 
LT  CONTAINS  CARD  IMAGE  RECORDS  ORQEREO  BY  THEIR  ASSOCIATED 
KEY. 


THE  UPDATE  OF  A  USER  OATA  SET  REQUIRES  ONLY  1  DISK 
REVOLUTION  FROM  THE  INITIAL  READ.  FROM  THE  ACTIVE  TERMINAL 
TABLE,  THE  LTI  OF  THE  ASSOCIATED  LT  IS  OBTAINEO.  THE  PROCESS 
OF  REAOING  THE  LT,  UPDATING  IT,  AND  WRITING  IT  OCCURS  WITHIN 
l  1/2  REVOLUTIONS  BECAUSE  THE  UPDATE  PROCESS  TAKES  LESS  THAN 
A  HALF  REVOLUTION.  FOR  UPOATES  WITHIN  A  DENSE  REGION  OF  THE 
USER  DATA  SET,  THE  MAXIMUM  DISK  READ/WRITES  IS  2.  FOR  SPARSE 
UPOATING  ,  THE  MAXIMUM  NUMBER  OF  DISK  READ/WRITES  IS  3. 

THE  PRIMARY  USE  OF  THE  USER  DATA  SET  IS  TO  STORE  USER 
PROGRAMS  IN  CARO  IMAGE  FORM.  HOWEVER,  A  SECONOARY  FEATURE 
PERMITS  XPL  BINARY  PROGRAM  IMAGES. 
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THE  HAP  >'  LUCK  PROVIDES  A  HAP  OF  THE  LOGICAL  TRACK ,  I.fc. 
whFKt  FACh  hluCk  IS  LOCATED.  THUS  THE  RELATIVE  ADDRESS  OF 
-iLUCK  4  I  >  F h F  AOORESS  OF  BLOCK  I  PLUS  THE  SUH  QF  THE  NUMBER 
OF  BYTES  IN  bLCCKS  L,  i  AND  3.  USING  THIS  HAPPING  TECHNIQUE, 
INDIVIDUAL  bLCCKS  MAY  BE  EXPANDED  OR  CONTRACTED  WITHOUT 
AFFECTING  THE  OTHER  BLOCK  ADDRESSES . 

THE  LAtULS  BLOCK  PROVIDES  INFORMATION  ABOUT  THE  LOGICAL 
TRACK  USfcLF.  IT  ASSOCIATES  THE  LOGICAL  TRACK  TO  A 
JO B /ACCOUNT  NUMBER  AND  A  DATA  SET  NAME.  FOR  SYSTEM  LOGICAL 
TRACKS,  THE  DATA  SET  NAMES  ARE  "DTCC"  CR  "D  PAGE".  IT  ALSO 
PROVIDES  INFORMATION  REGARDING  THE  NUMBER  OF  TIMES  THE 
LOGICAL  TRACK  HAS  SEEN  WRITTEN. 

THE  KEYS  BLOCK  PROVIDES  A  LIST  OF  KEYS  AND  ASSOCIATED 
POINTERS  FOR  u AT  A  CHAINING.  THE  POINTERS  ARE  LOGICAL  TRACK 
f  MSERS. 

THE  tlXTi _ SLOCK  PROVIDES  A  SEQUENTIAL  FILE  OF  KEYED 

RtCCRQS.  IF  THERE  IS  A  REQUEST  FOR  AN  UNKEYED  FILE,  THE 
LENGTH  QF  THE  KEY  AREA  SHOULD  BE  ZERO.  NOTE  THAT  BOTH  THE 
KEYS  AND  TEXTS  BLOCKS  HAVE  THE  SAME  STRUCTURE.  THE  SAME 
STRUCTURING  ALLOWS  ONLY  i  PROGRAM  TO  PERFORM  THE  DATA 
MANAG,MENT.  THE  SELF.CTIQN/LCCKOUT  AREA  IS  PROVIDED  TO  INSURE 
A  LEVEL  OF  PROTECTION  FOR  INDIVIDUAL  RECORDS.  SINCE  THE 
SELECTIQN/LOCKOUT  AREA  IS  OPTIONAL,  THE  LENGTH  OF  THE 
SELECT/LOCK  KEY  MAY  BE  ZERO. 

IMPORTANT  NOTE 

THIS  LOGICAL  TRACK  HAS  BEEN  ORGANIZED  IN  WORDS  EVEN 
THOUGH  THERE  IS  AN  OBVIOUS  INEFFICIENCY  IN  STORAGE  USAGE.  IT 
IS  MORE  IMPORTANT  TO  GAIN  SPEED  IN  COMPUTATION  THAN 
MINIMIZING  STORAGE. 
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USING  A  STANC-ALCNE  ROUTINE.  PASO  PRINT,  THE  FOLLOWING 
information  ABOUT  THE  OISK  file  HAS  BEEN  VERIFIED:  EACH 
PHYSICAL  TRACK  IS  CIVIOEC  1NTC  3  RECORCS.  RECORO  C  IS  A  16 
uYTE  RECORD  WHfcRE  THE  FIRST  8  BYTES  ARE  FOR  THE  CCUNT  ANO 
1  HE  OTHER  8  FOR  THE  CATA.  RECORDS  1  AND  2  ARE  3528  BYTE 
RECORDS  WHERE  THE  FIRST  8  BYTES  ARE  FOR  THE  COUNT  AND  THE 
REMAINING  3520  BYTES  FOR  THE  DATA.  THE  COUNT  AREA  IDENTIFIES 
THE  RECORD  (IN  TERMS  OF  CYLINDER  NUMBER,  HEAD  NUMBER,  AND 
k E CURD  NUMBER'  AND  INDICATES  THE  RECORD'S  FORMAT  (COUNT- 
DATA)  AND  LENGTH.  THE  DATA  AREA  CONTAINS  THE  RECORO 
INFCRMAT ION. 


IF  MORE  THAN  CNE  OISK  PACK  IS  AVAILABLE,  IT  IS  EASY  TO 
TREAT  THE  LIBRARY  AS  ONE  GARGANTUAN  DISK  PACK  WITH  A  TABLE 
TO  TRANSLATE  THE  LT#S  TC  THE  APPROPRIATE  DISK  PACKS.  THIS 
SCHEME  IS  EQUIVALENT  TC  SOFTWARE  PAGING  TECHNIQUES. 

IF  MORE  CORE  IS  AVAILABLE,  THEN  THE  DISK  READS  SHOULD 
BE  GuFFtREO.  ANY  OPERATION  UPON  THE  TRACK  WOULD,  HOWEVER, 
REQUIRE  IMMEDIATE  OISK  WRITES.  AGAIN  HIS  IS  TO  INCREASE 
RELIABILITY. 

THE  CARO  IMAGES  MAY  BE  "PRESSED-OECK*  TO  SOME  DEGREE. 
ESSENTIALLY  THE  TRAILING  BLANKS  COULD  BE  DELETED.  THIS 
EXTENSION  WILL  INCREASE  THE  STORAGE  CAPACITY  GF  THE  OISK 
FILE  ANO  NOT  SIGNIFICANTLY  DECREASE  THE  USUAL  PROCESSING. 
THE  MAJOR  DESIRE  FOR  SUCH  AN  IMPLEMENTATION  IS  TO  DECREASE 
THF  NUMBER  OF  CHARACTERS  TO  BE  TYPED  BY  THE  TELETYPES.  TO 
THIS  END,  THE  KEY  BLOCK  SHOULO  PRECEDE  THE  TEXT  BLOCK. 

IT  IS  NOW  CLEAR  THAT  THE  USE  OF  POINTERS  WITHIN  THE 
TRACK  IS  FEASIBLE  IF  IT  WCULD  DECREASE  DATA  MOVEMENT  AND  THE 
ACCED  EXPENSE  OF  2  BYTES  PER  RECORD  IS  NOT  PROHIBITIVE.  IN 
FACT  ONE  COULD  PROBABLY  KEEP  VARIABLE  LENGTH  RECORDS  WITH 
POINTERS.  AT  TRACK  OVERFLOW  TIME,  A  GARBAGE  COLLECTCR  WOULD 
BE  EMPLOYED.  HOWEVER,  TO  IMPLEMENT  SUCH  AN  INITIAL  DESIGN  IS 
TOC  COMPLICATED  A  TASK  CONSIDERING  THE  MAGNITUDE  OF  THE 
OVERALL  STRUCTURE  OF  THE  LIBRARY  MANAGEMENT.  IT  IS  CERTAINLY 
EASIER  TQ  OEVELGP  THE  EDIT  AND  DATA  MANAGEMENT  ROUTINES 
FIRST  KNOWING  THAT  ONE  IS  PLAYING  WITH  CARO  IMAGES. 
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TRACK  MANAGEMENT 

Al.LflUIlflh„Q£-mUi^I£A£^ 

THE  FREE  LOGICAL  TRACKS  ARE  KEPT  IN  A  POOL  IN  ORDER  TO 
ALLOCATE  THEM  IN  THE  MOST  EFFICIENT  MANNER.  SINCE  THE 
ALLOCATION  SCHEME  POSITIONS  THE  TRACKS  NEAR  THE  CENTRAL 
CYLINDER*  ALL  THE  DATA  SETS  MILL  BE  CLUSTERED  ABOUT  THE 
CENTRAL  CYLINOER.  THEN  THE  AVERAGE  SEEK  TIME  WILL  BE  NEAR 
MINIMUM. 

1.  EXAMINE  THE  CORE  TABLE'S  FREE  CYLINDER  BLOCK. 

2.  FIND  A  CYLINDER  NEAR  TO  THE  CENTRAL  CYLINDER. 

3.  EXAMINE  THE  BIT  MAP  OF  THE  FREE  LTS  IN  THE  CYLINDER 
BLOCK. 

A.  TAKE  THE  FIRST  FREE  LT  AND  INOICATE  THAT  IT'S 
ALLGCATEO. 

5.  SIGNAL  THAT  THE  OTOC  MUST  BE  REWRITTEN. 


COLLECTION  OF  f&£E_L061CAL  TRACKS 

THE  COLLECTION  OF  FREE  TRACKS  USUALLY  OCCURS  DURING  THE 
LOGICAL  TRACK  UNDERFLOW  CONDITION.  HOWEVER  UTILITY  PROGRAM 
WILL  ALSO  PERFORM  THIS  GARBAGE  COLLECTION  TO  ELIMINATE 
UNUSED  OR  EXPIRED  OATA  SETS. 

0.  EXAMINE  THE  CORE  TABLE'S  FREE  CYLINDER  BLCCK. 

1.  DETERMINE  THE  CYLINOER  NUMBER  FROM  THE  LT  NUMBER. 

2.  DETERMINE  THE  TRACK  NUMBER  FROM  THE  LT  NUMBER. 

3.  DETERMINE  THE  RECORO  NUMBER  FROM  THE  LT  NUMBER. 

A.  GET  THE  CYLINDER  BLOCK  CORRESPONDING  TO  THE 
COMPUTED  CYLINDER  NUMBER. 

5.  SET  THE  APPROPRIATE  BIT  TO  INDICATE  THAT  IT  IS 
FREE. 

7.  INOICATE  THAT  THE  OTOC  MUST  BE  REWRITTEN. 
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LOGICAL  TRACK.  QVfflf LOW 

WHEN  AN  INSERTED  CARO  FILLS  THE  LOGICAL  TRACK  TO 
CAPACITY,  A  LOGICAL  TRACK  OVERFLOW  CONDITION  EXISTS.  THE  LT 
MUST  THEN  BE  REORGANIZED  TO  ALLOW  FURTHER  EXPANSION.  THIS 
REORGANIZATION  REQUIRES  ONLY  4  OISK  REAC/WRITES.  THE  PROCESS 
REQUIRES  THE  FOLLOWING  STEPS. 

1.  SAVE  THE  LAST  15  CAROS  OF  THE  FILLEO  TRACK. 

2.  WRITE  OUT  THE  UPOATEO  TRACK. 

3.  GET  THE  PRIMARY  LOGICAL  TRACK. 

4.  GET  A  FREE  LOGICAL  TRACK. 

5.  UPDATE  THE  CHAINING  INFORMATION. 

6.  WRITE  OUT  THE  PLT. 

7.  CREATE  A  NEW  FLT  IMAGE  IN  THE  BUFFER. 

8.  INSERT  THE  SAVEO  15  CARDS. 

9.  WRITE  OUT  THE  NEW  TRACK. 


WHEN  THE  RESULT  OF  A  DELETION  REQUEST  LEAVES  ONE  OR  NG 
CARO  IN  A  TRACK,  A  LOGICAL  TRACK  UNDERFLOW  CONDITION  EXISTS. 
IF  THE  TRACK  IS  EMPTY,  IT  IS  SIMPLY  FREED  BACK  TO  THE  SYSTEM 
AND  REMOVED  FOR  THE  PRIMARY  TRACK  DIRECTORY.  FOR  THE  OTHER 
CASE  (ONLY  A  CARO  LEFT) ,  EITHER  THE  FIRST  OR  THE  LAST  CARO 
IS  INSERTED  INTO  THE  NEXT  LOGICAL  TRACK  AFTER  THE  TRACK  IS 
FREED  TO  THE  SYSTEM. 
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ami 


OATA  SET  MANAGEMENT 

HA-SEI-AlLflUIlOM 


*************************************** 

SURF  TABLE 


I  OSHEAO 


]  QSPNTR 


*************************************** 


*************************************** 

OSNOOE 


|  NEXT  OSNOOE 


*************************************** 


*************************************** 

OSNOOE 


I  NEXT  OSNOOE 


OSNOOE 


I  NEXT  OSNOOE 


NULL 
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aiiLI/^J2AIA-^X-Ai.i,££AlJLyJi 

THE  MULTI  OATA  SET  ALLOCATION  SCHEME  PROVIDES  THE 
SWAPPING  PROGRAM  THE  ABILITY  TO  ACCESS  MORE  THAN  ONE  OATA 
SET.  IT  ACCOMPLISHES  THIS  FUNCTION  BY  ALLOCATING  A  DATA  SET 
CONTROL  BLOCK,  OSNOOE,  FOR  FOR  EACH  DATA  SET.  THE  DSNODES 
CONTAIN  THE  INFORMATION  RECUIREO  TO  PROCESS  A  DATA  SET, 
NAMELY  THE  OATA  SET  NAME,  PRIMARY  LOGICAL  TRACK  NUMBER,  THE 
SECONDARY  LOGICAL  TRACK  NUMBER,  AND  THE  APPROPRIATE  KEYS. 

AT  INITIALIZATION,  A  LIST  OF  FREE  DSNODES  IS  CREATED 
WITH  FRFFHEAD  AS  THE  ACCESS  POINTER.  THEN  EACH  TERMINAL  IN 
THE  SYSTEM  IS  ALLOCATED  A  DSNOOE. 

WHENEVER  A  "SELECT"  OR  "CREATE"  COMMAND  IS  ISSUEO  FROM 
"SMON",  A  NEW  DSNOCE  IS  OBTAINED  FROM  THE  FREE  OSNOOE  LIST 
AND  STACKED  ONTO  THAT  TERMINAL'S  LIST.  EACH  TERMINAL  HAS  A 
POINTER  TO  ThE  HEAD  OF  OSNOOE  STACK  ,  OSHEADr  AND  A  POINTER 
TC  THE  CURRENT  DSNOOE,  DSPNTR.  WHEN  THE  DATA  SETS  ARE  NO 
LONGER  REQUIREO,  ALL  DSNODES  EXCEPT  THE  LAST  ONE  IN  THE 
STACK  IS  REMOVED  AND  RETURNED  TO  THE  FREE  DSNOCE  LIST. 
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SEL.EfcIlflttJe&fl£&Si 


THE  SELECTION  PROCESS  ALLOWS  THE  USER  TO  ACCESS  THE 
UHTSS  LIBRARY.  THE  APPROPRIATE  ENTRIES  IN  THE  UHTSS  TABLES 
WILL  INDICATE  THAT  FACT. 

1.  EXAMINE  THE  CORE  TABLE'S  DIRECTORY  PAGE  BLOCK. 

2.  USING  THE  JOB/ACCQLNT  NUMBER,  OBTAIN  THE  ASSOCIATE^ 
DP  ENTRY. 

3.  Ff JM  THE  ASSOCIATED  OP  ENTRY,  OBTAIN  THE  LT#  OF  THE 
DP. 

4.  READ  IN  THE  ASSOCIATED  DIRECTORY  PAGE. 

5.  USING  THE  JOB/ACCOUNT  NUMBER  AND  THE  DATA  SET  NAME, 
OBTAIN  THE  ASSOCIATED  DATA  SET  BLOCK. 

6.  FROM  THE  ASSOCIATED  DATA  SET  BLOCK,  OBTAIN  THE 
PRIMARY  LTI  OF  THE  DATA  SET. 

7.  FILL  THE  UHTSS  TABLES  WITH  THE  APPROPRIATE 

INFORMATION. 

8.  UPOATE  THE  CURRENT  OATE  FIELD  AND  WRITE  IT  BACK 
OUT. 

9.  ISSUE  WARNING  IF  CURRENT  DATE  IS  GREATER  THAN 

EXPIRATION  OATE. 

10.  POSITION  THE  OATA  SET  TO  THE  FIRST  RECORO  ON  THE 
OATA  SET.  (SKIP  THIS  IF  THE  DATA  SET  IS  LOADABLE.) 


THE  CREATION  PROCESS  INVOLVES  THE  CREATION  OF  A  FREE 
TRACK  IMAGE  IN  THE  BUFFER  ANO  WRITING  IT  OUT.  THE  DIRECTORY 
PAGE  IS  ALSG  UPDATED. 


SCRATCH  P.afi£E$S 

SCRATCHING  WRITES  A  FREE  TRACK  IMAGE  ONTO  DISK  FOR  EACH 
LT  TRACK.  THEN  THE  ENTRY  IN  THE  DIRECTORY  PAGE  IS  OELETEO. 
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A  LOADABLE  DATA  SET,  LOS,  IS  AN  USER  DATA  SET  IN  THE 
UHTSS  LIBRARY  WHICH  CONTAINS  THE  XPL  GENERATED  CORE  IMAGE  OF 
A  LOAD  MOOULE.  EACH  TRACK  OF  THE  OATA  SET  CONTAINS  3000 
BYTES  CF  THE  CORE  IMAGE.  THE  FIRST  TRACK  CONTAINS  A  CONTROL 
BLCCK  CF  60  BYTES. 

"HE  GENERATION  OF  A  LOS  REQUIRES  THAT  THE  COMPILER 
GENERATE  THE  ENTIRE  OATA  SET  IN  CORE  WITH  THE  CONTROL  BLOCK. 
THE  COOE  MUST  BE  RELOCATABLE.  THE  COMPILER  THEN  ISSUES  THE 
LINK  COMMAND,  WHICH  SELECTS  A  OATA  SET.  UPON  SUCCESSFUL 
COMPLETION  OF  THE  COMMAND,  THE  NOAOL"  COMMAND  WITH  A  KEY  IS 
ISSUEO  TO  WRITE  OUT  THE  DATA  SET. 

THE  FUNCTION  OF  "DAOL*  IS  TO  WRITE  OUT  BLOCKS  OF  CORE 
IMAGES  ONTO  DISK.  THE  USER  MUST  GIVE  A  KEY  IN  THE  COMMAND 
FOR  THAT  BLOCK  OF  CORE  CORRESPONDING  TO  "AREALOC".  NOTE  THAT 
NOT  ONLY  CORE  Ih'GES  BUT  BLOCKED  CARD  IMAGCS  MAY  BE  WRITTEN. 
"OAQL"  ACTS  EXACTLY  LIKE  "INSERT",  NAMELY  AODS  A  NEW  LOGICAL 
TRACK  IF  THE  KEY  OOES  NOT  EXIST  AND  REPLACES  IT  OTHERWISE. 

IN  OROER  FOR  THE  USER  PROGRAM  TO  READ  A  DATA  SET,  HE 
MUST  FIRST  DECIOE  HOW  HE  IS  GOING  TO  ACCESS  THE  RECORDS. 
CURRENTLY,  DATA  SETS  ARE  READ  ONLY  FCR  BOTH  COMPILER  INPUT 
AND  INPUTTING  COMPILERS.  THUS  THE  DATA  SET  MUST  BE  SFLFCTFn 
IN  OROER  TO  OBTAIN  THE  PRIMARY  LOGICAL  TRACK  ADDRESS.  SINCE 
INPUTTING  COMPILERS  ANO  COMPILER  INPUT  ARE  SPECIAL  KINDS  OF 
REQUESTS  THE  LINK  COMMAND  PERFORMS  THE  SELECT  AND  STUFFS  THE 
SURF  BUFFER  WITH  SOME  CONTROL  INFORMATION.  THE  MOST 
INFORMATION  IN  THE  SURF  BUFFER  IS  MEANINGLESS  FOR  COMPILER 
INPUT  WHILE  SCME  OF  THE  OATA  IS  MEANINGFUL  FCR  INPUTTING 
COMPILERS.  THE  CONTROL  INFORMATION  IS  DISCUSSED  IN  THE 
CONTROL  RECQRC  FORMAT  SECTION. 

THE  MOST  EFF1CIFNT  METHQO  OF  READING  IN  A  OATA  SET  IS 
TO  REAO  IN  LOGICAL  TRACKS.  FOR  INPUTTING  COMPILERS,  A 
LOGICAL  TRACK  IS  3000  BYTE  OF  COOE.  BUT  FOR  COMPILER  INPUT, 
A  LOGICAL  TRACK  CONTAINS  SEVERAL  CARD  IMAGES,  I.E.  IT  IS 
ESSENTIALLY  A  VARIABLE  NUMBER  OF  CARO  IMAGES  (80  BYTES!. 
THUS  THE  TARGET  AREA  SPECIFIED  IN  AREALQC  MUST  BE  3536 
BYTES,  3520  FOR  THE  BLOCKEO  RECORDS  AND  16  BYTES  FOR  THE 
BLOCK  CONTROL  INFORMATION  (NUMBER  OF  CAROS  IN  THE  TRACK  ANO 
OTHER  OATA).  TO  ADO  SOME  FLEXIBILITY  THE  LOAD  COMMAND  MUST 
I NCLUDE  THE  INDEX,  WHERE  INOEX  TELLS  WHICH  LOGICAL  TRACK  IS 
TO  BE  REAO.  NOTE  THAT  INDEX  RANGES  FROM  0  TO  fSUBBLOCKS-1. 
THUS  TO  REAO  IN  A  COMPILER,  ONE  MUST  ISSUE  AS  MANY  LOAOS  AS 
THERE  ARE  LOGICAL  TRACKS.  AREALQC  MUST  BE  INCREMENTED  EVERY 
TIME.  TO  REAO  IN  COMPILER  INPUT,  THERE  IS  AN  AOOITIONAL 
COMPLEXITY,  I.E.  THE  USER  MUST  OEBLOCK  THE  RECORDS  USING  THE 
BLCCK  CONTROL  INFORMATION. 
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&flNIBfli.,.a*CQBC  ECftflil 

THE  CONTROL  BLOCK  HAS  THE  FOLLOWING  FORMAT: 

WORD  CONTENTS 

0  NUMBER  OF  BYTES  OF  FULL  PROGRAM  COOE 

1  NUMBER  OF  BYTES  OF  FULL  DATA  CODE 

2  NUMBER  OF  PROGRAM  RECORDS 

3  NUMBER  OF  DATA  RECOROS 

4  NUMBER  OF  BYTES  IN  A  RECQRO 

5  NUMBER  OF  BYTES  IN  THE  LAST  PROGRAM 

RECORD 

6  NUMBER  OF  BYTES  IN  THE  LAST  DATA  RECORD 

8  NUMBER  OF  LOGICAL  TRACKS  IN  THE  DATASET. 

(AUGMENTED  ONLY  DURING  ThE  LINK  COMMAND) 

9  NUMBER  OF  BYTES  OF  PROGRAM  COOE 


WORDS  0  TO  6  ARE  GENERATED  BY  THE  XPL  COMPILER  AND  ARE 
NOT  MANIPULATED  BY  TSS- LIBRARY .  WORD  8  IS  STUFFED  INTO  THE 
SURF  BUFFER  ONLY  FOR  THE  LINK  COMMAND.  IT  DOES  NOT  EXIST  ON 
THE  DATA  SET.  WORO  9  IS  GENERATED  BY  ISS-L1BRARY  ANO  GIVES 
THE  RELATIVE  ADDRESS  OF  THE  START  OF  THE  DATA  AREA  FOR  USE 
BY  SMQN. 
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JOB  MANAGEMENT 

ISS-UaaAfl*  QUEUE  PROCESSING 

T SS-L I BRARY  QUEUE  MAY  HAVE  hORE  THAN  ONE  REQUEST  AT  ANY 
TIME.  EACH  REQUEST  MAY  REQUIRE  EITHER  SINGLE  SERVICE  OR 
MULTIPLE  SERVICE.  THE  NEW  OESIGN  PHILOSOPHY  IS  TO  PROCESS 
ALL  REQUESTS  AS  SINGLE  SERVICE  IN  A  ROUND  ROBIN  FASHION.  THE 
REASONS  FOR  THIS  OESIGN  IS  PRIMARILY  TO  GIVE  EQUITABLE 
TREATMENT  TO  REQUESTS  UNO  THEREFORE  THE  USERS )  AND 
SECONOARILY  TO  GIVE  SOME  PSYCHOLOGICAL  REASSURANCE  TO  THE 
USER. 


THIS  ROUND  ROBIN  APPROACH  IS  THE  SAME  AS  TIME  SLICES  IN 
THE  LARGER  SYSTEM  ENVIRONMENT.  THUS  A  USER  WHOSE  REQUEST  IS 
QUEUE 0  AFTER  FIVE  OTHERS  WILL  RECEIVE  SOME  SERVICE  AFTER 
PROCESSING  THE  FIFTH  SERVICE  REQUEST.  THIS  APPROACH  DIFFERS 
RADICALLY  FROM  THE  INITIAL  OESIGN  WHICH  WAS  A  FIFO  QUEUE 
WHERE  THERE  WAS  NO  DISTINCTION  BETWEEN  SINGLE  SERVICE  AND 
MULTIPLE  SERVICE  REQUESTS.  FOR  SINGLE  SERVICE  REQUESTS  FIFO 
OR  ROUND  ROBIN  PROCESSING  IS  EQUIVALENT.  HOWEVER *  FOR 
MULTIPLE  SERVICE  REQUESTS*  THE  "ROUND  ROBIN"  APPROACH  LETS 
THE  USER  KNOW  EVERY  SO  OFTEN  (DEPENDS  ON  THE  QUEUE  LENGTH) 
THAT  HIS  REQUEST  IS  BEING  SERVICED*  THUS  REASSURING  HIM  THAT 
HE  IS  STILL  ACTIVE  WITHIN  THE  SYSTEM. 

THERE  IS  STILL  S  AN  INHERENT  INEFFICIENCY  IN  THE  ROUND 
auaiil  APPROACH  WITHIN  THE  TSS-L18RARY  ENVIRONMENT.  THIS 
ENVIRONMENT  MUST  NOW  REAO  IN  THE  PRIMARY  LOGICAL  TRACK  TO 
DETERMINE  WHICH  SECONDARY  LOGICAL  TRACK  IS  TO  BE  OPERATED 

upon,  thus  there  are  aooitional  cisk  reaos  every  time  a 
RtQUEST  IS  SERVICEO.  THE  FIFO  SCHEME  COULD  SAVE  THE 
NECESSARY  INFORMATION  AND  THUS  ELIMINATE  MOST  OF  THE  READING 
OF  THE  PRIMARY  TRACKS. 

THE  IMPLEMENTATION  OF  multiple  SERVICE  ROUTINES 
REQUIRES  A  NEW  EXAMINATION  OF  THE  USUAL  COMMAND  STRUCTURE. 
ESSENTIALLY  A  FIELO*  COUNT.  MUST  KEEP  A  RECORD  OF  THE  NUMBER 
OF  TIMES  THE  COMMAND  IS  TC  BE  EXECUTEO.  ADDITIONAL  FIE10S 
MUST  CONTAIN  THE  PROPER  INFORMATION  TO  SERVE  AS  INDICES  f OR 
VARIOUS  PARAMETERS.  NOTE  THAT  THE  COMMANO  NEEC  NOT  BE  WITHIN 
THE  BUFFER  SINCE  LLfllXLE  ALREAOY  INDICATES  THE  COMMANO.  THUS 
IF  COUNT  IS  ZERO,  THE  REQUEST  IS  SINGLE  SERVICE*  OTHERWISE 
If  IS  MULTIPLE  SERVICE  REQUEST.  EVENTUALLY  WHEN  "COUNT" 
BECOMES  ZERC,  The  REQUEST  WILL  BE  QELETEO  FROM  THE  QUEUE. 
FOR  COMPLEX  OPERATIONS  IN  "OUTPUTER"  SUB1PTYP  IS  USED  TO 
DISTINGUISH  THE  SUB-FUNCTIONS. 

FINALLY,  Th€»C  IS  another  complication,  I.E.  THE  HASP 
SUBMISSION.  THE  ROUND  ROBIN  APPROACH  CANNOT  BE  USEO  SINCE  IT 
WOULD  INTERSPERSE  ONE  USER’S  JCL  WITH  ANOTHER’S  JCL.  FOR 
THIS  CASE,  ONLY  ONE  USER  IS  PROCESSED  WHILE  THE  CTHER  HASP 
REQUESTS  ARE  PASSED  OVER.  THUS  WITHIN  THE  RGUNO  RCBIN 
STRUCTURE  THERE  IS  A  SINGLE  SERVER  SUBQUEUE. 
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QUEUE  RftfifcES&ihG 


I  QUEUE  1 


I  QUEUE?  I 


*  SURF 

♦ 

NOOE  * 

W-  • - 

*  1 

* 

POINTER  I  * 

m  *  - - 

* 

•  ™ 

•a******************************* **•**«*» 

*  SURF  NOOE  * 

*  * 

• 

♦  1 

POINTER  I  * 

*  SURF 

NODE  • 

♦  1 

POINTER  |  * 

^  • 

■*4"  •  * 

null 


IRON  PLACES  REQUESTS  IN  A  QUEUE  FOR  TSS-LI6RARV.  hHEN 
ISS-U8RARY  HAS  SATISFIED  THE  REQUEST,  IT  POSTS  THE 
COMPLETION  OF  ITS  TASK  AND  T MON  REMOVES  THE  ELEMENT  FROM  THE 
QUEUE,  "QUEUE  1*  POINTS  TO  THE  FIRST  REQUEST  #H!lE  "QUEUE?" 
TO  THE  LAST,  IN  THE  SURF  TABLE  FOR  A  TERMINAL  THERE  IS  * 
POINTER  TO  THE  NEXT  REQUEST  IN  THE  TSS-LISRAAy  QUEUE.  WHEN 
THE  POINTER  IS  NEGATIVE,  TSS-L I 8RARY  hft$  RtACHEC  THE  END  OF 
THE  QUEUE  ANO  PROCEEDS  TO  REPROCESS  THE  QUEUE  FROM  THE 
BEGINNING  TILL  ALL  REQUESTS  HAVE  BEEN  SATISFIED.  MHEN  ALL 
REQUESTS  HAVE  BEEN  SATlSFIEO,  TSS-L I 8RARY  MILL  wAIT  UNTIL 
TMON  GIVES  IT  MORE  MORK. 
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THE  NUMBER  OF  SERVICES  UfcTSS  OFFERS  IS  LIMITED.  IN 
CROER  TO  UTILIZE  THE  FULL  CAPABILITY  OF  THE  OPERATING 
SYSTEM,  UHTSS  PROVIDES  A  METHOD  OF  SUBMITTING  JOBS  TO  THE 
BATCH  PROCESSOR  VIA  THE  TERMINALS. 

THE  HASP  SYSTEM  PROVIDES  AN  INTERNAL  REAOER  WHICH  IS 
ALLOCATED  USING  A  DO  CARO  ESSENTIALLY  IT  IS  A  PSUEOO  CARO 
READER  BEHAVING  TO  HASP  As  AN  ORDINARY  CARO  REAOER. 

THE  HASP  COMMAND  ROUTES  THE  CAROS  TO  THE  INTERNAL 
HEADER .  THESE  CAROS  HOWEVER  MUST  HAVE  THE  PROPER  JCL  CAROS 
I  JUST  LIKE  A  NORMAL  JOB  SUBMITTED  TO  THE  CARD  READER*.  BOTH 
THE  PRINT  AND  PUNCH  COMMANDS  GENERATE  THE  PROPER  JCL  FOR  THE 
USER  USING  THE  SYSTEM  DEFAULTS.  NOTE  THAT  ALL  •/*•  CARDS  ARE 
REPLACED  BY  CAROS. 


UMMG-IbE  I£S_Ufl8ABlL.£flGfiBAlj 


ALL  CCMM<  J  FOR  THE  SYSTEM  ARE  PUNCHED  ON  CARDS  IN 

exactly  the  same  format  as  on  the  consoles,  all  replies  by 

THE  SYSTEM  are  PRINTED  OUT.  DISPLAY  IS  THE  SAME  AS  PRINT. 
THE  FORMAT  OF  THE  'OSTING  IS  THE  TERMINAL  NUMBER  ( ALWAYS  0), 
THE  CURRENT  DATA  SET  NAME  (MAY  BE  BLANK ) *  THE  CURRENT  TIME 
OF  OAY  IN  BINARY  IN  TERMS  OF  HUNDREDTHS  OF  A  SECOND,  AND  A 
MESSAGE.  THE  MESSAGE  MAY  8E  THE  COMMAND  TO  BE  EXECUTED,  THE 
RESPONSE  OF  THE  SYSTEM  (*:.....),  A  STATUS  REPORT  (SELECT: 
DATA  SET  SELECTED  PROPERTY!,  AN  ERROR  MESSAGE  (CREATF? 
DUPLICATE  NAME  OR  FINALLY  THE  REQUEST  SATISFIED 
MESSAGE  WITH  THE  CURRENT  I/O  COUNT. 

NOTE:  ONLY  COMMANDS  TO  THE  LIBRARY  PROGRAM  ARE 
RECOGNIZED.  YOU  CANNOT  EXECUTE  A  PROGRAM  BUT  YOU  MAY  HASP  A 
DATA  SET.  THE  BATCH  VERSION  WILL  TERMINATE  ON  ANY  ERROR 
EXCEPT  END  OF  DATA  SET. 

NOTE:  THE  COST  OF  USING  THE  BATCH  VERSION  IS  COMPUTED 
AS  A  NORMAL  BACKGROUND  JOB.  THE  UHTSS/2  ACCOUNTING  SCHEME 
OOES  NOT  APPLY.  DEPENDING  UPON  THE  APPLICATION  THE  REGION 
SIZE  ANO  I/O  COUNTS  MAY  BE  SIGNIFICANT. 

FIRS1  LINE  PRINTED  BY  THE  BATCH  VERSION  INFORMS  YOU  AS 
TO  THE  SIZE  OF  THE  DYNAMIC  AREA  AVAILABLE  TO  DAOL/LOAD.  IT 
MUST  BE  LARGER  THAN  YOUR  XPL  FORMATTED  DATA  SET.  OTHERWISE 
THE  PROGRAM  TERMINATES.  THIS  DYNAMIC  AREA  IS  A  FUNCTION  OF 
THE  REGION  SIZE  OF  THE  STEP.  THE  BATCH  VERSION  TAKES  ABOUT 
90K  TO  EXECUTE.  IF  YOU  WISH  TO  LOAD/LAOL,  YOU  MUST  ADO  THE 
APPROPRIATE  AMOUNT  TO  90K . 
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TO  CREATE  A  LG  JO.  _<Lfc  C*TA  SET  ON  THE  TIME  SHARING  FILE, 
THE  FOLLOWING  COMMANDS  MUST  BE  EXECUTED: 

1)  HI  ‘PROGRAMMER  NAME* 

(NOTE  THAT  *«!»##*#  IS  YOU  JOB/ACCOUNT 
NUMBER.  AT  THE  MOMENT  THE  SYSTEMS 
JOB/ACCOUNT  NUMBER  IS  COOOOOOO) 

2)  CREATE  'DATA  SET  uAHE* 

THE  DATA  SET  NAME  IS  THE  NAME  OF  THE 
PROGRAM  YOU  WANT  TO  EXECUTE. 

31  DACL  ‘DATA  SET  NAME* 

YOUR  LOADABLE  DATA  SET  MUST  BE  IN  XPL 
FORM  ON  INPUT2.  THE  DOCARO  MUST  REDEFINE 
THE  DATA  SET  TO  BE 

DCB=  5R  ECFM  =  FB*  LRECL*80 , BLKS I ZE=7200 I 

NOTE:  THE  AP  ROPRIATE  MESSAGES  WILL  INFORM  YOU  OF  THE 
COMPLETION  OF  EACH  REQUEST  ANO  THE  PROPER  EXECUTION  OF  EACH 
REQUEST. 


XPL  I HPLEMENTAT ION »  NOVEMBER  7,  1969 


A8 


SOURCE  LAYOUTS 

IflQM/LlMM*  SQUMJLLAXflm 

. - -  REALTHNG  - - - . 

I  I 

|  ******  MONITOR  ***********  | 

I  *  CALL  SEABASS  *  I 

j  **************************  | 

I  I 

|  ******  SEABASS  ***********  1 

l  *  IDENTIFY  LIBRARY  *  J 

t  *  ATTACH  LIBRARY  *  | 

j  **************************  j 

I  I 


. - SURF  AREA - - - 

I  I 


. - LIBRARY  PROGRAM - . 

I  1 

|  «*************************  j 

|  *  DATA  AREA  *  I 

|  **************************  ] 

I  i 

]  **************************  | 

|  *  PROGRAM  AREA  *  | 

|  **************************  | 

I  I 


. - TMON  PROGRAM - - - 

I  I 

I  CALL  MONITOR  (PARAMETERS);  I 

I  I 


. - MAIN  PROGRAM - - - . 

I  I 

|  CALL  TMON;  I 

i  I 


THE  DIAGRAM  DETAILS  THE  PROGRAM  STRUCTURE  OF 
TMGN/L I BRARY.  THE  REAL  _  THING  IS  A  LOAO  MOOULE  OF  ASSEMBLY 
PROGRAMS.  THE  REST  ARE  WRITTEN  IN  XPL.  THE  SURF  AREA  IS  A 
COLLECTION  OF  DECLARATIONS.  SIMILARLY  THE  DATA  AREA  OF  THE 
LIBRARY  PROGRAM  IS  JUST  DECLARATIONS.  BOTH  TMON  AND  LIMAS* 
ARE  INTERNAL  PROCEDURES  TO  THE  MAIN  PROGRAM  WITH  THE  SURF 
AREA  GLOBAL  TO  ALL  THREE  PROGRAMS. 
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IBflAZULBfiiai  SOUBC£.LAmi 

THE  PROCESS  OF  VITALIZING  THE  LIBRARY  PROGRAM  HAS  THE 
FOLLOWING  STEPS: 

A)  THE  MAIN  PROGRAM  CALLS  TMON. 

81  AFTER  TMON  INITIALIZES  HIS  AREAS,  HE  CALLS  THE 

MONITOR  ANO  ALSO  PASSES  A  PARAMETER  LIST 
(ONE  SUCH  PARAMETER  IS  THE  ADDRESS  OF 
TS$_LI BRARY 1 . 

C)  THE  MONITOR  (AN  ASSEMBLY  PROGRAM)  CALL  SEABASS  (ALSO 
IN  ASSEMBLY). 

0)  SEABASS  PROCEEDS  TO  "IDENTIFY"  LIBRARY  ANO 

"ATTACHES"  THE  PROGRAM.  THIS  PROCESS 
MAKES  LIBRARY  KNOWN  TO  OS/MVT  AS  A  TASK 
ANO  EXECUTES  IT  AS  SUCH. 

E)  EVENTUALLY  LIBRARY  IS  EXECUTED  AS  A  TASK  ANO  SPRINGS 
TO  LIFE. 
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. - SURF  AREA 


************************** 
*  * 

*  LITERALS  * 

*  * 
**************  *****(1*^**** 

************************** 


* 

* 

* 


EC8  AREa 


* 

* 

* 


************* ************* 


************************** 


* 

* 

* 


QUEUE  AREA 


* 

* 

* 


************************** 


************************** 


* 

* 


SURF  AREA 


* 

* 

* 


************************** 


************************** 


* 

* 

* 


OSNQOE  AREA 


* 

* 


************************** 


THE  SURF  AREA  CONSISTS  OF  LITERALS ,  ECBS,  QUEUES.  SURF, 
AND  THE  OSNOOE  AREA.  THESE  DATA  ELEMENTS  ARE  THE  ONLY 
GLOBALS  REQUIRED  FOR  COMMUNICATION  BETWEEN  TMON  AND  LIBRARY. 
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SUBE-iaU-SflUBCf-mflUI 

THE  LITERALS  ENABLE  THE  SVSTEM  PROGRAMS  TO  REFER  TO 
ELEMENTS  OF  SURF  AND  DSNOCE  IN  A  STRAIGHT-FORWARD  MANNER .  IT 
PARALLELS  THE  USE  OF  DSECTS  OF  ASSEMBLER  LANGUAGE  OR 
PREPROCESSOR  STATEMENTS  OF  PL/i.  NOTE  THAT  THE  OBJECT  CODE 
IS  NOT  OPTIMIZED  BY  THE  USE  OF  SUCH  MACROS. 

THE  ECBS  PROVIDE  SYNCHRONIZATION  OF  TASKS  (NAMELY  TMON, 
LIBRARY*  AND  IGCONTRL).  IN  TIME  THE  NAMING  CONVENTION  WILL 
BE  REGULARIZED  TO  REFLECT  PROGRAMS*  NOT  PROGRAMMERS. 

THERE  ARE  THREE  QUFUES  IN  THE  OVERALL  SYSTEM.  TMON 
MAINTAINS  EACH  ONE  FOR  THE  SUBSIDIARY  TASKS,  IGCONTRL,  SMON, 
AND  LIBRARY.  THESE  QUEUES  ARE  JUST  THE  HEAD  AND  TAIL 
POINTERS  TO  SURF  BLOCKS  WHICH  ARE  LINKED  IN  THE  APPROPRIATE 
MANNER. 

SURF,  THE  SYSTEM  USER*S  FILE  IS  AN  ARRAY  OF  CONTROL 
BLOCKS.  EACH  TERMINAL  IS  ASSIGNEO  A  BLOCK  WHICH  CONTAINS  ALL 
THE  PERTINENT  INFORMATION  TO  PROVIDE  SERVICE  TO  THAT 
TERMINAL.  THE  SIZE  HAS  BEEN  DECLARED  TO  BE  500  WORDS. 
HOWEVER  THERE  ARE  CURRENTLY  ONLY  6  TERMINALS  OEFINEO  WITH  65 
WORDS  PER  BLOCK.  THUS  SOME  AREA  OF  CORE  IS  UNUSED.  FROM  AN 
AESTHETIC  POINT  OF  VIEW,  SURF  BLOCKS  SHOULD  BE  DYNAMIC,  LIKE 
MAIN  STORAGE  TO  HANDLE  TRANSIENT  TERMINALS. 

ON  THE  OTHER  HAND,  DSNCOE  IS  MORE  DYNAMIC.  PRESENTLY  IT 
CAN  HANDLE  40  DATA  SET  NODES! A  OSNODE  IS  20  WORDS  ANO  THE 
AREA  IS  800  WORDS).  SURF  CONTAINS  POINTERS  TO  THE  OSNOOES 
(ACTUALLY  ONLY  INDICES).  THERE  IS  A  STACK 
ALLOCATION/COLLECTION  MECHANISM  THAT  MANAGES  THIS  AREA. 
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LIBRARY  DATA  AREA  SOURCE  LAYOUT 


.- -  DATA  AREA 


***** 

* 

» 

* 


globals  ************ 


INITIAL  .  * 

VARIABLES  .  * 

. .  * 

MAPPING  .  * 

ARRAYS  .  * 


**«*********£***** ******** 


*****  transient  area  ***** 


•  •••*o*»«********  9* 

♦  #  •  * 

*  •  * 

♦  .  BUFF  .  * 

»  •  •  " 

™  9  •  ^ 

********* ******* ********** 

*****  resident  area  ****** 

♦  ....... ......a*.  * 

♦  .  •  * 

*  .  TABLE  .  * 

*  •  •  * 

*  .  GLOBALS  .  * 

*******  'padding  .*♦** 


FREE 

IMAGE 


THERE  ARE  FOUR  MAJOR  GLOBAL  AREAS  WITHIN  THE  LIBRARY 
PROGRAM.  THE  FIRST  GLOBAL  AREA  CONSISTS  OF  VARIABLES  WITH 
INITIAL  VALUES  ANO  A  SET  CF  MAPPING  ARRAYS.  IN  FACT  IF  THERE 
WERE  MORE  MACRO  SPACE  IN  THE  XPL  COMPILER,  MOST  OF  THE 
VARIABLES  WOULD  BE  LITERALS.  THE  MAPPING  ARRAYS  CONTAIN 
STRUCTURAL  INFORMATION  REGARDING  EITHER  DISK  SUFFER  AREAS 
(BUFF  OR  TABLE  BUT  NOT  BOTH). 
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LIBRARY  DATA  AREA  SOURCE ^LAYOUT 

THE  SECONO  GLOBAL  AREA  IS  A  TRANSIENT  AREA*  BUFF,  FOR 
THE  DISK  OPERATIONS.  CURRENTLY  IT  IS  3524  BYTES  EVEN  THOUGH 
THE  RECORD  SIZE  IS  3520.  THE  EXTRA  FOUR  BYTES  ARE  FOR  KICKS. 

THE  LAST  TWO  GLOBAL  AREAS  ARE  OVERLAPPED.  THE  RESIDENT 
AREA*  '.ABLE*  IS  INITIALIZED  WITH  THE  CURRENT  DTOC.  AFTER 
INITIALIZATION  THE  AREA  IS  NEVER  REAO  INTO  AGAIN. 
OCCASIONALLY  THE  OTOC  IS  WRITTEN  OUT,  BUT  NEVER  READ  IN 
THEREAFTER.  CURRENTLY  THE  DTOC  CONTAINS  LESS  THAN  400  WORDS 
BUT  THE  BUFFER  AREA  IS  880  WORDS •  IN  ORDER  TO  UTILIZE  THIS 
SPACE*  THE  LAST  GLOBAL  AREA  IS  GVERLAYEO  ON  TO  THE  FULL 
TABLE  BUFFER.  THIS  AREA  CONTAINS  WORK  AREAS*  PADDING  AND 
FR£E_IMAGE. 

THE  WORK  AREA  CANNOT  BE  INITIALIZED  SINCE  IT  IS  OVERLAY 
DURING  INITIALIZATION.  PAOOING  IS  AN  AREA  TO  INSURE  THAT  THE 
DISK  RECORD  DOES  NOT  OVERRUN  SOME  OTHER  AREA.  FREE.IMAGE  IS 
THE  DISK  IMAGE  OF  A  FREE  LOGICAL  TRACK  IIT  IS  CORE  RESIDENT 
TO  REOUCE  DISK  READS). 
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. - PROGRAM  A^EA - . 

I  I 

|  ********************** ****  t 

I  *  * 

I  *  StRVlCfc  ANO  * 

(  *  MANAGEMENT  * 

I  *  ROUTINES  * 

j  *  * 

|  ************************** 

I 

|  ************************** 

I  *  x 

(  *  LIBRARY  * 

I  REQUEST  DRIVERS  * 

!  *  * 

I  ************************** 

I 

I  *  *  ************************ 

j  *  * 

|  *  MAIN  PROGRAM  * 

|  *  LIBRARY  DRIVER  * 

1  *  * 

|  ************************** 


THE  SUBROUTINE  STRUCTURE  IS  SIMPLE  SINCE  XPL  REQUIRES 
THAT  PROCEDURES  MUST  EXIST  BEFORE  THEY  ARE  REFERENCED..  THERE 
ARE  VERY  FEW  INTERNAL  PROCEDURES.  MOST  OF  THE  ROUTINES  ARE 
CLUSTERED  TO  REFLECT  SIMILAR  FUNCTIONS;  HOWEVER,  THE 
OROfc.ilNG  IS  MAINLY  HISTORICAL. 
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SUBRGwTINE  COMPONENTS 


INITIALIZATION 

THERE  ARE  THREE  PHASES  FOR  INITIALIZATION.  THE  FIRST 
PHASE  IS  A  ONE-SHOT  EXECUTION,  I.E.  IT  OCCURS  ONLY  AT  THE 
START  OF  THE  PROGRAM  ANC  IS  NEVER  EXECUTEO  AGAIN.  THE  OTHER 
PHASES  OCCUR  DURING  EVERY  REQUEST  FOR  SERVICE. 

AT  THE  FIRST  CALL  TO  THE  LIBRARY  SYSTEM,  THE  ROUTINE 
"INITIALIZE*  IS  CALLED  TO  FIND  THE  CURRENT  OTOC  AND  READ  IT 
INTO  ThE  CORE  TABLE,  SUPPLY  THE  PROPER  ADDRESS  REQUIRED 
THROUGHOUT  ThE  PROGRAM,  ANO  TO  SAVE  THE  FREE  LOGICAL  TRACK 
IMAGE  IN  CORE  FOR  LATER  USE.  IT  ALSO  CREATES  A  FREE  DSNOOE 
LIST  ANO  ALLOCATES  A  NODE  TO  EACH  SURF  TERMINAL. 

AT  EVERY  REQUEST  A  LIST  OF  ADDRESSES  MUST  BE 
CALCULATED.  ONE  PHASE  INITIALIZES  POINTERS  THAT  DEPEND  UPON 
"TERMAD"  FOR  SURF  FIELDS.  THE  OTHER  Ph„SE  INITIALIZES 
POINTERS  FOR  THE  OSNOOES  WHICH  DEPEND  UPON  "DSPNTR". 


£V££1A1S 

IN  ORDER  TO  SAVE  CORE  STORAGE,  VARIABLES  NOT  USED 
DURING  INITIALIZATION  OR  VARIABLES  NOT  INITIALIZED  APE 
CECLAREO  AFTER  "VABLE".  "TABLE*  IS  THE  BUFFER  ARE.*  FOR  THE 
DTQC ,  WHICH  MUST  BE  3520  BYTES.  BUT  ONLY  ABOUT  1600  BYTES  Ii 
USED  FOR  THE  OTOC  WHICH  IS  READ  IN  ONLY  ONCE  DURING 
INITIALIZATION.  THE  OTHER  1920  BYTES  CAN  BE  EFFECTIVELY  USED 
FOR  OTHER  VARIABLES.  NOTE  THAT  "PADDING"  IS  AN  ARRAY  THAT 
ASSURES  THAT  THE  AGGREGATE  SIZE  OF  -TABLE",  THE  OTHER 
VARIABLES,  AND  "PAOOING"  IS  GREATER  ThAN  3520. 
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L  flUi}A£LQ_efiiK£iilA  Q 

THE  MAJOR  ROUTINE  THAT  OEALS  WITH  COMMANO  PROCESSING  IS 
"PARSING"  WHICH  DEALS  WITH  A  COMMAND  SYNTAX  THAT  FOLLOWS: 

<COMMAND>  :=  <COMMAND  L  I  S T >  |  <COMH AND  LIST>  ; 


CCOMMAND 

LISTS  := 

CCOMMAND  HEADS 

<C  OMMANO 

LISTS  :=  CCOMMAND  LISTS 

CCOMMAND  OPTIONS 

CCCMMANO 

HEADS  :* 

CCOMMAND  OPTIONS 

CCOMMAND 

HE AOS  := 

CNULLS 

CCOMHANO 

OPT  IONS 

:*  CPO  SIT  I ONAL  OPTIONS 

CCOMMAND 

OPTIONS 

:*  CKEYWCRO  OPTIONS 

<DEL IMI TER> 


<POS l T  10NAL  OPT IQN>  :=  <OPTION> 

<KEVWORO  OPT  ION>  :*  <K£YWORD>  *  <OPHON> 
<OELIMITER>  :*  <BL ANK>  |  <COMMA> 

<OPT I ON>  :=  <STRING  OF  CHARACTERS  WITHOUT  8 L ANKS> 
<QPT I ON>  :=  •  <STR ING  GF  CHARACTERS  WITH  BLANKS>  • 


P.S.  THE  STANOARD  PROBLEM  OF  APOSTROPHES  OCCUR.  TO 
REPRESENT  THEM  USE  TWO  SUCCESSIVE  APOSTROPHES,  I.E. 

IT  IS  IMPORTANT  TO  NOTE  THAT  IN  THE  COMMANO  PROCESSING, 
THE  FIRST  CALL  TO  "PARSING"  IS  A  DUMMY  BECAUSE  "TMON"  HAS 
ALREADY  DECODED  THE  COMMAND.  THE  FUNCTION  CF  THE  FIRST  CALL 
IS  TO  SET  UP  THE  PROPER  "IMAGE". 


THE  "PARSING"  ROUTINE  IS  THE  MOST  IMPORTANT  ROUTINE 
BECAUSE  IT  00 ES  ALL  THE  ANALYZING  OF  THE  COMMAND  SYNTAX.  THE 
ROUTINE  REQUIRES  THAT  THE  GLOBAL  VARIA8LE  " IMAGE”  9E  FILLED 
WITH  THE  COMMAND  STRING,  "BUFFER".  AT  EACH  CALL  TO 
"PARSING",  TWO  ANSWERS  ARE  RETURNED  VIA  GLOBAL S  "K.EYWORO" 
AND  "OPTION".  THE  ROUTINE  IS  CALLEC  AS  MANY  TIMES  AS 
REQUIRED  TO  PROCESS  ALL  ThE  OPTIONS.  NCTt  THAT  THE  COMMAND 
ITSELF  MUST  BE  VIEWED  AS  AN  OPTION.  ALSO  ThE  "IMAGE"  IS 
REPLACED  WITH  THE  REMAINDER  CF  THE  COMMAND  STRING.  SO  A 
COMMANO  THAT  HAS  TWO  OPTIGNS  WILL  HAVE  3  CALLS  TG  "PARSER". 
FINALLY  THE  ROUTINE  IS  A  FUNCTION  TO  INDICATE  END  OF 
PROCESSING,  I.E.  EITHER  THE  SEMI-COLON  WAS  ENCOUNTERED  OR 
COLUMN  80.  THE  RETURN  IS  FALSE  FOR  THE  END  OF  PROCESSING 
SIGNAL. 


Best  Available  Copy 
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&scQtto.gfl  slumps 

THE  T MO  METHODS  OF  RECORD  POSITIONING  ARE  RELATIVE  AND 
ABSOLUTE.  BOTH  METHODS  MUST  DEAL  Ml TH  THE  STRUCTURE  OF  THE 
OATA  SET  UNOER  UHTSS. 

ABSOLUTE  POSITIONING  REQUIRES  COUNTING  ThE  RECORDS  IN 
THE  DATA  SET  STARTING  FROM  THE  BEGINNING.  SINCE  NEITHER  THE 
UHTSS  TABLES  NOR  THE  LIBRARY  STRUCTURE  HAS  THE  CURRENT 
RECORD  NUMBER,  THE  PRIMARY  IT  MUST  BE  ACCESSED  TO 
SEQUENTIALLY  COUNT  THE  NUMBER  OF  RECORDS  IN  THE  OATA  SET. 
THIS  INVOLVES  ACCESSING  EACH  SECONDARY  LT  FOR  THE 
INFORMATION.  EACH  LT  HAS  THE  NUMBER  OF  RECORDS  IN  IT  BUT 
THERE  IS  NO  FIELD  IN  THE  PIT'S  ASSOCIATED  LT  BLOCK  FOR  THIS 
NUMBER  (IT  WO'JLO  DOUBLE  THE  NUMBER  OF  ACCESSES  TO  THE  DISK 
IN  OROER  TO  KEEP  THE  FILES  UPDATED!. 

THE  RELATIVE  METHOD  USES  ThE  RECORD  KEY  TC  FINO  THE 
POSITION  OF  THE  RECORO.  ThF  KEY  IS  SEARCHED  THROUGH  ThE 
ASSOCIATED  LT  TABLES  TO  FINO  THE  PROPER  SECONDARY  LT.  THEN 

THAT  track  is  read  in  and  the  key  is  again  used  to  find  its 

POSITION  WITHIN  THE  TRACK. 

COMPARING  BOTH  METHOCS.  THE  RELATIVE  METHOD  IS  SUPERIOR 
TO  THE  ABSOLUTE  METHOO.  THE  FORMER  METHOD  REUUIRES  CNl Y  TfcO 
ACCESSES  WHILE  THE  LATTER  METHOO  REQUIRES  AT  LEAST  TWO  AND 
POSSIBLY  MANY  MORE  IF  THE  RECQRC  IS  NEAR  THE  ENC  OF  A  LARGE 
DATA  SET.  THE  TRAOE-CFFS  ARE  SIMILAR  TO  SEQUENTIAL 
PROCESSING  VERSUS  RANDOM  PROCESSING. 
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iLLQ£jb^AMi*£lJj^iI 

THE  MOST  IMPORTANT  ROUTINES  TO  THE  LIBRARY  SYSTEM  ARE 
THE  BLOCK  MANAGEMENT  PROGRAMS.  THESE  PROCEDURES  PROVIOE  THE 
NECESSARY  TABLE  LOOK-UP  PROCEDURE  AND  THE  VITAL  BLOCK 
UPCATING  FUNCTIONS. 

THE  "MAP"  ROUTINE  PROVIDES  A  STRUCTURE  MAPPING  OF  A 
LOGICAL  TRACK.  FROM  THE  BLOCK  INFORMA. *QN  WITHIN  THE  TRACK, 
THE  ROUTINE  CALCULATES  ANO  SAVES  PERTINENT  INFORMATION 
REGARDING  THE  TRACK.  THESE  VALUES  ARE  CONTAINED  THE  GLOBALS 
"ABLK",  THE  RELATIVE  AODRESS  OF  EACH  BLOCK  WITHIN  THE  ARRAY 
(EITHER  -BUFF"  OR  -TABLE" l ,  "ASU8S-,  THE  RELATIVE  ADDRESS  OF 
THE  SUB-BLOCKS,  -IBLKS-,  THE  NUMBER  OF  WOROS  IN  THE  BLOCK, 
-(KDATA- ,  NUMBER  OF  WORDS  IN  OATA  AREA  OF  THE  SUB-BLOCK, 
"#KEYS",  NUMBER  OF  WORDS  IN  THE  KEY  AREA,  «#LOCK",  NUMBER  OF 
WORDS  IN  THE  LOCKOUT  AREA,  "#SUBS"»  NUMBER  OF  SUB-BLOCKS  IN 
THE  BLOCK,  ANO  -#TEXT«,  THE  NUMBER  OF  WORDS  IN  THE  TEXT 
AREA. 

-BDAM"  PROVIDES  THE  INSERTION  AND  DELETION  OF  SUB¬ 
BLOCKS  IN  BLOCKS  3  ANO  4.  IT  ALSO  PROVIDES  RETRIEVAL  OF  SUB- 
BLOCKS  FROM  THESE  BLOCKS. 

FINALLY,  -ISAM"  SEARCHES  THE  DIRECTORY  TABLES  GIVEN  A 
KEY  AND  FINOS  THE  POSITION  OF  THE  KEY  WITHIN  THE  TABLE.  THE 
SEARCH  IS  STRICTLY  SEQUENTIAL.  IT  RETURNS  A  FLAG  TO  INOICATE 
THE  KIND  OF  POSTION,  l.E.  LESS  THAN  A  KEY,  EQUAL  TO  A  KEY, 
BETWEEN  TWO  KEYS,  OR  OUTSIDE  THE  RANGE. 
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Jiaisfi.  caaBjuM  cinch  s 

THE  LIBRARY  PROGRAMS  COMMUNICATE  WITH  THE  TERMINAL  OR 
THE  MONITOR  VIA  POSTS  AND  WAITS.  .‘HE  "SYSTEM**  ROUTINE 
INFORMS  THE  MONITOR  THAT  THE  LIBRARY  PROGRAM  HAS  CRASHED, 
THE  "CONSOLE"  PROGRAM  COMMUNICATES  WITH  THE  TERMINAL,  THE 
"POST"  ROUTINE  IS  THE  BASIC  TRANSMITS  TO  THE  MONITOR*  AND 
THE  "WAIT"  PROGRAM  TELLS  THE  MO.1  *TQR  THAT  THE  LIBRARY 
PROGRAMS  IS  FINISHED. 

THE  SURF  BUFFER  IS  STORED  IN  A  WORK  AREA.  ALL 
MANIPULATION  WITH  THE  8UFFER  IS  DONE  WITH  RESPECT  TO  THE 
WORK  AREA.  WHEN  THE  RESULTS  ARE  TO  BE  PASSEO  BACK  VIA  THE 
SURF  BUFFER,  THE  LIBRARY  MUST  WAIT  TILL  THE  BUFFER  IS  FREE. 
THEN  THE  BUFFER  IS  STUFFED  FROM  THE  WORK  AREA.  THIS  OCCURS 
IN  2  ROUTINES:  CONSOLE  AND  LINK. 


QS.CfimittUAIiQBS 

IN  ORDER  TO  MOVE  DATA  FRCM  ONE  PROTECT  REG IGN  INTO 
ANOTHER,  UHTSS  HAS  AN  SVC  WHICH  WILL  PUT  THE  PROGRAM  IN  ZERO 
PROTECT  KEY.  THE  ROUTINES  INVOLVED  ARE: 

G£T_INTO_PROT£C\_KEV_Z£RO. 

GET_OUT__OF_PROTECT_KEY_ZERO. 
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lQlQSXSCftACUS 

MOST  OF  THE  IOOSVNCRAC IES  ARE  NOT  MAJOR  RQA08LQCKS  BUT 
AT  TIMES  CONSTITUTE  AN  UNNECESSARV  DIGRESSION  IN  PROGRAMMING 
TO  SOLVE  THEM.  MOST  OF  THE  SOLUTIONS  HAVE  BEEN  DONE  USING 
"INLINE"  COOING. 

THE  XPL  IMPLEMENTATION  OF  COREWQRQ  REQUIRES  A  WORD 
j DRESS  WHILE  NOWHERE  WITHIN  THE  STRUCTURE  OF  XPL  IS  THERE 
ANY  FACILITY  FOR  CBTAINNING  A  WORO  ADDRESS  DIRECTLY.  AS  A 
RESULT  OF  THIS-  "MAPPER"  PROVIDES  BYTE  ADDRESSING  FOR  WORD 
ARRAYS. 

SIBJWG.S 

SlRINGS  ARE  PASSED  AS  STRING  DESCRIPTORS  WITH  AN  8  BIT 
LENGTH  AND  A  24  BIT  ADDRESS  FIELD.  THERE  ARE  ENTRIES  WITHIN 
THE  UHTSS  TABLE  THAT  SHOULD  BE  TREATED  AS  STRINGS  BUT 
BECAUSE  THERE  ARE  NO  EQUIVALENCE  OR  DEFINED  STATEMENTS*  WE 
MUST  PERFORM  THE  MAPPING  OURSELVES.  THE  ROUTINE  "STRING"  HAS 
A  PSUEDQ-DESCkIPTOR  AS  AN  ARGUMENT  AND  RETURNS  THIS 
DESCRIPTOR  AS  THE  PROPER  VALUE  FOR  A  CHARACTER  PROCEDURE. 
THUS  USING  "STRING"  AS  A  FUNCTION  WITH  A  WORD  THAT  HAS  THE 
H IGH-OROER  BYTE  SET  TO  SOME  LENGTH  AND  THE  LOW-ORDER  3  BYTES 
TO  SOME  ADDRESS  *  WE  CAN  USE  ELEMENTS  OF  AN  ARRAY  AS  AN  XPL 
CHARACTER  STRING. 

SINCE  OATA  FIELDS  MUST  BE  PHYSICALLY  MOVED,  THE  XPL 
CONVENTIONS  OF  SETTING  DESCRIPTORS  EQUAL  IS  UNSATISFACTORY. 
"MCVEBYTES"  MOVES  BLOCKS  OF  UP  TO  256  BYTES  FROM  "SOURCE"  TO 
"TARGET".  BOTH  SOURCE  OR  TARGET  ARE  CORE  ADDRESSES  WHICH  ARE 
USUALLY  STRING  DESCRIPTORS.  "MOVER"  CALLS  "MOVEBYTES"  BUT 
MOVES  IN  TERMS  OF  WORDS. 

THERE  IS  PERHAPS  A  BUG  WITHIN  XPL.  THERE  SEEMS  TO  9E 
SOME  SCRT  OF  FAILURE  TO  CONCATENATE  PROPERLY  WHEN  THE  FREE 
STRING  AREA  IS  OVERFLOWED  ANO  COMPACT  IT ICAT ION  MUST  OCCUR. 
FOR  THIS  REASON  THERE  WILL  BE  NO  CONCATENATION  WITHIN  THE 
PROGRAMS. 

HKTfcftNAL 

SINCE  XPL  LACKS  THE  ABILITY  TO  BRANCH  TO  ROUTINES  WHOSE 
ADDRESSES  WERE  PASSED  AS  PARAMETERS,  "MASS"  WAS  DESIGNED  TO 
PERFORM  A  SIMPLE  BALR. 
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SUBROUTINE  ANATOMY 

THIS  SECTION  DESCRIBES  EACH  SUBROUTINE  USED  IN  THE 
LIBRARY  PROGRAM.  EACH  DESCRIPTION  INCLUDES  A  NARRATIVE  ON 
THE  FUNCTIONS  ANO  QUIRKS,  A  LIST  OF  PROCEDURES  I T  INVOKES 
AND  FINALLY  A  LIST  OF  GLOBALS  IT  REFERENCES.  T.*;E  ORDER  OF 
THE  SUBROUTINES  IS  THE  ORDER  REQURIED  BY  XPL  AND  MY  OWN 
PERSONAL  QUIRK. 


SI&IAS 

DESCRIPTIVE  NOTES: 

TAKES  A  PSEUOO-DESCRIPTOR  ANO  RETURNS  IT  AS  AN  XPL 
DESCRIPTOR.  A  PSEUDO-DESCRIPTOR  IS  A  WORD  WITH  THE 
HIGH  ORDER  BYTE  BEING  THE  LENGTH  OF  THE  STRING 
MINUS  1  INULL  STRINGS  ARE  REPRESENTED  BY  A  ZERO 
WORD).  THE  LOW  ORDER  3  BYTES  IS  THE  MACHINE 
ADDRESS. 

UA RE£B 

DESCRIPTIVE  NOTES: 

PERFORMS  THE  SAME  FUNCTION  AS  COREWORD.  DIFFERENCE 
IS  THAT  IT  USES  AN  AOORESS  ThAT  IS  A  PARAMETER  TO  A 
SUBROUTINE. 

INVOKED  PROCEDURES: 

INLINE 

LAE 


DESCRIPTIVE  NOTES: 

BLANKS  OUT  A  STRING.  THE  DESCRIPTOR  MUST  POINT  TO 
AN  AREA  BELOW  FREEBASE. 

INVOKED  PROCEDURES: 

INLINE 


DESCRIPTIVE  NOTES: 

MOVES  UP  TO  256  BYTES  AROUNO.  THE  REASON  FOR  THE 
BCTR  3,0  IS  THAT  LIMHED  IS  THE  NUMBER  OF  BYTES  TO 
BE  MCVEO,  BUT  THE  MACHINE  REQUIRES  THAT  THE  LENGTH 
BE  THE  LENGTH  OF  THE  STRING  MINUS  ONE. 

INVOKED  PROCEDURES: 

INLINE 


DESCRIPTIVE  NOTES: 

MOVES  BLOCKS  OF  WOROS  ABOUT.  TRIES  TO  OPTIMIZE  BY 
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MOVING  SLOCKS  OF  256  BYTES  AT  A  TIME. 

INVOKED  PROCEDURES: 

M0VE8YTES 


UAQJLhG 


DESCRIPTIVE  NOTES: 

PUTS  LEADING  BLANKS  INTO  A  STRING.  THE  TARGET 
STRING  MUST  BE  BELOW  FREEBASE. 

INVOKEO  PROCEDURES: 

LENGTH,  MOVEBYTES,  STRING,  ZAP 


i&AlilMi 


DESCRIPTIVE  NOTES: 

PUTS  TRAILING  BLANKS  INTO  A  STRING.  THE  TARGET 
STRING  MUST  BE  BELOW  FREEBASE. 

INVOKED  PROCEDURES: 

LENGTH:  MOVEBYTES,  STRING,  ZAP 


descriptive  notes: 

CHARACTER  FUNCTION 

PERFORMS  BINARY  TO  HEXADECIMAL  CHARACTER  STRING 
CONVERSION  FOR  OUTPUTTING. 

INVOKED  PROCEDURES: 

SUBSTR 


BACKMQYE 


DESCRIPTIVE  NOTES: 

MAKES  ROOM  FOR  A  BLOCK  BY  MOVING  THE  BLOCKS  AFTER 
IT  A  BLOCK  UP. 

INVOKED  PROCEDURES: 

MOVE 


1QQGJUM6 


DESCRIPTIVE  NOTES: 

LOG  THE  TIME,  TERMINAL,  CA1 A  SET  NAME.  AND  MESSAGE, 
ONLY  IF  SYSTEM  TRACE  IS  LESS  THAN  1. 

INVOKEO  PROCEDURES: 

STRING,  SUBSTR 

REFERENCED  GLOBALS: 

SYSTEM  TRACE 


I 
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OESCRIPTIVE  NOTES: 

WRITE  TO  THE  OS  SYSTEM  TYPEWRITER/OPERATOR,  INLINES 
THE  SVC.  MAKE  SURE  TO  SAVE  GENERAL  REGISTER  15  ELSE 
XPL  WILL  BE  SCREWED  UP. 

INVGKEO  PROCEDURES: 

INLINE 

fi£I .  imiRfllit  L- 

DESCRIPTIVE  NOTES: 

PUTS  THE  PROGRAM  IN  PROTECT  KEY  ZERO  BY  ISSUING  A 
SPECIAL  SVC. 

INVOKED  PROCEDURES: 

INLINE 

£fc  I  -  QU I . Of..  r£CI£C  T  „.&£Y-  Lt W 

DESCRIPTIVE  NOTES: 

GETS  THE  PROGRAM  OUT  OF  PROTECT  KEY  ZERO,  ISSUES  A 
SPECIAL  SVC. 

INVOKED  PROCEDURES: 

INLINE 

mi 

DESCRIPTIVE  NOTES: 

SIGNAL  THE  COMPLETION  OF  AN  EVENT. 

INVOKED  PROCEDURES: 

INLINE 

WAIT 

DESCRIPTIVE  NOTES: 

AWAIT  THE  COMPLETION  OF  THE  EVfcNT  • 

INVOKED  PROCEDURES: 

INLINE 

WAIT  m,BU£££B 

DESCRIPTIVE  NQTtS: 

TELL  f MCN  THAI  I'M  GOING  TU  I'St  THt.  SURI  BUrrcR. 

WAIT  TILL  IT'S  OK. 

INVGKEO  PROCEDURES: 

POST,  WAIT 


REFERENCED  GL08ALS: 

CMON.QECB,  IOSTAT ,  ORIGIN,  IEhMAC 
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REQUEST  INPUT 

DESCRIPTIVE  NOTES: 

ASK  TMGN  TO  GIVE  ME  INPUT*  WITHOUT  EXAMINING  THE 
CONTENTS  OF  THE  BUFFER.  WE  ARE  NO  LONGER  IN  COMMAND 
MODE  BUT  IN  MOOE  52  (AT  THE  MOMENT  INSERT  MODE). 

INVOKED  PROCEDURES: 

POST 

REFERENCED  GLOBALS: 

COMPLETED  STATUS  TERMAO 

EQaSfllE 

DESCRIPTIVE  NOTES: 

WRITE  TO  THE  TERMINAL.  NOTE  THAT  WE  MUST  WAIT  UNTIL 
THE  SURF  BUFFER  IS  FREE  FOR  USAGE.  IF  THE 

SUBROUTINE  NAME  *X»  HAS  AN  AS  THE  FIRST 

CHARACTER,  THEN  THE  MESSAGE  GOES  TO  THE  ACTIVE^LINE 
(OF  THE  ?260 *  S) .  OTHERWISE  IT  GOES  TO  THE 

FORMATTING  LINE.  NOTE  THAT  THE  SURF  BUFR  IS  STUFFED 
WITH  THE  CONTENTS  OF  THE  WORKING  BUFFER. 

invoked  fhcccDuRlS. 

BYTE,  LENGTH,  LOGGING,  MOVE,  MQVEBYTES,  POST, 
TRAILING,  WAIT,  WAIT_FQR_BUFFER,  ZAP 

REFERENCED  GLOBALS: 

APAGE,  BUFFER,  BUFR,  TERMAD 


DESCRIPTIVE  NOTES: 

KILL  MY  PART  OF  TMF  PROGRAM.  WE  HAVE  A  DISASTROUS 
ERROR.  FCRCr  tOCr.NC.. 

INVOKED  PROCEDURES: 

OPERATOR,  WAIT 

REFERENCED  GLOBALS: 

SYSTEN_TRACE 

LlBBJBY-CRAStl 

DESCRIPTIVE  NOTES: 

THE  COMMAND  WAS  NCI  IN  THE  BUFFER.  KILL  MY  PROGRAM. 

INVOKED  PROCEDURES: 

SYSTEM 

CQHMfeBI-BlMAai 

DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 
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CONVERT  A  CHARACTER  STRING  TO  A  BINARY  NUMBER, 
INCLUDING  NEGATIVE  NUMBERS.  IF  THE  RETURN  IS  TRUE, 
THEN  THERE  IS  A  CONVERSION  ERROR.  OTHERWISE  THE 
ANSWER  IS  RETURNED  IN  'VALUE*. 

INVOKED  PROCEDURES: 

BYTE,  LENGTH,  OPERATOR 

REFERENCED  GLOBALS: 

VALUE 


liiOLAZ 

DESCRIPTIVE  NOTES: 

FIXED  FUNCTION 

PERFORMS  A  SEARCH  OF  A  STRING  FOR  A  GIVEN  SUBSTRING 
WITH  PARAMETERS  TO  TELL  WHERE  TO  START  ANO  STOP 
SEARCHING  ANO  HOW  TO  INCREMENT  THE  SEARCH. 

INVOKED  PROCEDURES: 

LENGTH,  SUBSTR 

ioJLUl 


DESCRIPTIVE  NOTES: 

FIXED  FUNCTION 

SAME  AS  "INDEX"  FUNCTION  OF  PL/I.  CAN'T  USE  "INDEX" 
BECAUSE  IT'S  A  LITERAL. 

INVOKEO  PROCEDURES: 

INOEX2,  LENGTH 


U&SJM 


DESCRIPTIVE  NOTES: 

IOGICAL  FUNCTION 

TAKES  A  STRING  AND  RETURNS  THE  KEYWQKD/CPT ION  USING 
THE  SYNTAX  OEF  INED  FOR  THE  COMMANOS.  HANDLES 
APOSTROPHES  OK.  THE  PARAMETER  DELIMITER  IS  A  BLANK 
OR  COMMA.  THE  COMMAND  OEUMlTtR  IS  A  SEMI-COLCN. 
CONTINUING  MAY  NOT  BE  RESET  PROPERLY,  T..AT  IS  WHY 
IN  TSS.LIBRARV  ON  THE  FIRST  CALL,  IT  IS  RESET. 

•WARNING*  PARSING  DESTROYS  IMAGE  IF  LITERAL  STRINGS 
ARE  USEC.  THE  TECHNIQUE  USING  PARSING  MAKES  IMAGE  = 
BUFFER.  NOTE  THAT  BUFFER  IS  AN  ARRAY. 

INVOKED  PROCEDURES: 

BYTE,  INOEX1,  LENGTH  OPERATOR,  SUBSTR 
REFERENCED  GLOBALS: 

IMAGE,  KEYWORO,  OPTION,  VALUE,  CONTINUING 
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&A£ 

OESCRIPTIVE  NUTES: 

ANALYZES  EITHER  BUFFERS  ANO  FILL  THE  MAPPING  ARRAYS 
WITH  THE  APPROPRIATE  VALUES. 

INVOKED  PROCEDURES: 

MAPPER,  SYSTEM 

REFtRENCEO  GLQBALS: 

•BLKS,  ABLK ,  ASUBS,  ASUBS,  #DATA  ,  »KEYS,  #LOCK, 
•TEXT,  CURRENT.BUFFER,  FREE.AREA 

UGAfl 

OESCRIPTIVE  NOTES: 

MANIPULATES  SUBBLQCKS  OF  BLOCKS  3  OR  A.  INSERTS, 
DELETES,  ANO  RETRIEVES.  IF  THE  SUBBLOCK#  IS  OUT  OF 
RANGE,  THE  SUBBLOCK#  IS  RESET  TO  THE  BOUNDARY 
LIMIT. 

1NVOKEO  PROCEDURES: 

BACKMQVE,  COREWOhD,  MAP,  MOVE ,  OPERATOR 
REFERENCED  GL09ALS: 

•TEXT,  ASUBS,  CURRENT_BUFFER ,  FREEWARE A,  #BLKS, 

•  SUBS 

UAB 


OESCRIPTIVE  NOTES: 

FIXEO  FUNCTION 

SEARCHES  THROUGH  A  LIST  OF  KEYS  TO  SEE  IF  A  GIVEN 
KEY  IS  WITHIN  m  RANGE  OF  THEM.  RETURNS  FLAG  AND 
SUB*. 

INVOKED  PROCEDURES: 

STRING,  OPERATOR 

REFERENCED  GLQBALS: 

•KEYS,  «TEXT,  ASUBS,  IDATA ,  FLAG,  SUB#,  CCNDCOOE 


FIND  BIT 


OESCRIPTIVE  NOTES: 

FIXEO  FUNCTION 

TRIES  TO  FINO  A  FREt  BIT  GIVEN  A  FREE  CYLINDER 
BLOCK.  CALCULATES  THE  APPROPRIATE  LOGICAL  TRACK 
NUMBER.  RETURNS  ZERO  OTHERWISE. 

INVOKED  PROCEDURES: 

FREE_BLK 
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DESCRIPTIVE  NOTES: 

FlXEO  FUNCTION 

SEAKCHES  THROUGH  THE  CORE  TABLE'S  BLOCK  *»  FROM  THE 
CENTRAL  CYLINOER.  RETURNS  THE  LT|. 

INVOKED  PROCEDURES: 

30AM,  FIN 0_ BIT.  MAP,  SYSTEM 

REFERENCED  GLOBALS: 

ATABLE,  A SUBS  A8UFF,  REWRITE 

££L£I££ 

DESCRIPTIVE  NOTES: 

FREES  A  LOGICAL  TRACK  BY  RESETTING  THE  APPROPRIATE 
BIT  IN  THE  PROPER  FREE  CYLINOER  BLOCK. 

INVOKED  PROCEDURES: 

BDAM ,  HAP 

REFERENCED  GLOBALS: 

ATABLE.  LT«,  AB'JFF,  REWRITE 

DESCRIPTIVE  NOTES? 

HAKE  SURE  THAT  THE  LT«  IS  WITHIN  THE  BCUMS  OF  THE 
DISK  FILE. 

INVOKEO  PROCEDURES: 

SYSTEM 

REFERENCED  GLOBALS: 

LAST_TRACK# ,  LTB 

diU]£ 

DESCRIPTIVE  NOTES? 

DETERMINES  IF  THE  OTOC  SHOULD  BE  WR.TiEN.  IF  SO, 
WRITES  IT. 

INVOKEO  PROCEDURES? 

FILE,  TRACK_CH£C  K 


OESCR I PT ! Vfc  NOTES: 

READS  IN  TMfc  DESIRED  LOGICAL  TRACK.  CHECKS  FIRST  TO 
SEE  IF  II  IS  ALREADY  IN  CORE.  IF  IT  IS  JUST  ACT  AS 
IF  IT  WAS  READ  IN. 


INVOKED  PROCEDURES 
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FILE,  MAP,  RITEY 

REFERENCED  GLQ8ALS : 

LTV,  IOCCUNT,  BUFF ,  LAST_LT§ 


££AJ2£ 

OESCRIPTIVE  NOTES: 

RE  AOS  IN  THE  TRACK  ANQ  TRIES  TO  GET  THE  HIGH  AND 
LOW  KEYS  I  CANNOT  BE  OQNE  FOR  L0A0A3LE  DATA  SETS*. 

INVOKED  PROCEDURES: 

BDAM,  MOVE,  READY 

REFERENCED  GLOBALS: 
iTEXT,  LO,  HI 


OESCRIPTIVE  NOTES: 

WRITES  THE  LOGICAL  TRACK  ONTO  OISK. 

INVOKED  PROCEDURES: 

FILE,  RlTfcY,  TRACK_CHECK 

REFERENCED  GLOBALS: 

IT fl,  ABLK,  BUFF,  IOCOUNT,  LAST_LT# 

AikflUIi-HSJlfiilfi 

DESCRIPTIVE  NOTES: 

OBTAINS  A  FREE  DSNQDE  FOR  A  TERMINAL. 

INVOKED  PROCEDURES: 

SYSTEM 

REFERENCED  GLOBALS: 

DSNOOE,  OSPNTR ,  DSHEAD,  0CB1,  DC32,  FREEHEAD,  COUNT 

fafcfc-OSttflflE 

OESCRIPTIVE  NOTES: 

FREES  A  DSNODE  LIST  AND  PUTS  EACH  DSNOOE  BACK  ON 
THE  FREE  OSNQDE  LIST,  EXCEPT  THE  LAST  ONE.  IT  IS 
ALWAYS  ALLOCAT'O  TO  THE  SURF  TERMINAL. 

REFERENCED  GLOBALS: 

OSNODE,  DSHEAD,  CSPNTR,  FRcEHEAO,  COUNT 

IfilLULUi  2Shflfl£ 

DESCRIPTIVE  NOTES: 

INITIALIZES  DATA  SET  PARAMETER  POINTERS. 


REFERENCED  GLOBALS 
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OSNOOE,  FREEHEAO,  OSPNTR,  OSHEAC,  LO,  CURRENT,  HI, 
STOPKEY,  C UR RENT_ OSNOOE 

INITIALIZE 

DESCRIPTIVE  NOTES: 

READ  IN  THE  CURRENT  DTOC,  INITIALIZE  POINTERS,  GET 
THE  OATE,  SET  UP  THE  FREE  OSNOOE  LIST  AND  ALLOCATE 
ONE  TO  EACH  TERMINAL.  CALCULATE  TODAY'S  DATE  (TRY 
TO  HANDLE  LEAP  YEAR,  MIGHT  NCT  WORK). 

INVOKED  PROCEDURES: 

ALLOC AT E.CSNODE ,  OATE,  FILE,  GET_FILE,  MAP,  MOVE, 
STRING,  SUBSTR,  SYSTEM 

REFERENCED  GLOBALS: 

ATA8LE,  APADOING,  UCE.CQUNT,  LAST.TRACKi,  iSUBS, 
ABUFF,  BUFFER,  AFREE,  APAGE,  OATE.EXP,  DATE_NOW, 
NEXT-KEY,  DATE.LIMIT,  CATE_TQDAY , 

FREE_LOGlCAL_TRACK,  LTI ,  FREE_APEA,  DSNOOE,  DSHEAD, 
OSPNTR,  NUM_TERM?  £m'RY_LENGTH 

REINITIALIZE 

DESCRIPTIVE  NOTES: 

FREES  THE  LT  AND  MRITES  A  FREE  LOGICAL  TRACK  OUT. 

INVOKED  PROCEDURES: 

FREETRK,  MOVE,  WRITE„F iLE 

REFERENCED  GLOBALS: 

ABUFF,  A_FR£E„IMAGE 

DESCRIPTIVE  NOTES: 

FIXED  FUNCTION 

EXAMINES  THE  CORE  TABLE  FOR  THE  JOB/ACCOUNT  NUMBER. 


INVOKED  PROCEDURES: 

ISAM,  MAP,  MOVE,  STRING 

REFERENCED  GLOBALS: 

A JOB ,  APAGE,  ATABLE,  FLAG 

LflflU-ilJEAfig 

DESCRIPTIVE  NOTES: 

FIXEO  FUNCTION 

EXAMINES  THE  DIRECTORY  PAGE  FOR  THE  JOB/ACCOUNT 
NUMBER  AND  DSNAME. 
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INVOKED  PROCEDURES: 

BDAM ,  GET.FILE,  ISAM,  MOVE,  STRING 

REFERENCED  GLGBALS: 

SUB*,  LTf,  APAGE,  AJQ8,  AOSET,  FLAG,  ABUFF 

DESCRIPTIVE  NOTES: 

FILLS  IN  THE  LABEL  BLOCK  WITH  THE  RIGHT  STUFF. 

INVGKEO  PROCEDURES: 

MOVE 

REFERENCED  GLOBALS: 

ABLK ,  BUFF,  AJOB,  AOSET,  AUSER_NAME,  LT* 

jJ^Ij._£MA-SEI_ELQLlS 

DESCRIPTIVE  NOTES: 

FILLS  IN  THE  DATA  SET  BLOCK  FOR  THE  DIRECTORY  PAGE. 

INVOKED  PROCEDURES: 

MOVE 

REFERENCED  GLOBALS: 

LT#,  APAGE.  OATE_TOOAY,  DATE.LIMIT,  AUSER.NAME, 
AJOB,  AOSET 

DATA  SET  ERROR 

DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 

CHECK  TO  SEE  IF  A  DATA  SET  HAS  ALREADY  BEEN 
SELECTEO. 

INVOKED  PROCEDURES: 

OPERATOR,  STRING,  SYSTEM 

REFERENCED  GLOBALS: 

AOSET 

m...  block.  me 

DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 

CHECK  TO  SEE  IF  THE  TEXT  SIZE  IS  LESS  THAN  OR  EQUAL 
TO  20  WORDS,  SINCE  INSERT  AND  DELETE  USES  SCRATCH 
ARRAYS  OF  ONLY  20  WOROS. 

INVOKED  PROCEDURES: 

OPERATOR 
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REFERENCED  GLGBALS: 
LT#»  f TEXT 


DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 

CHECK  FOR  KEYS  OF  LENGTH  >6.  FORCE  BAD  CCNDCODE  IF 
IT  IS. 

INVOKED  PROCEDURES: 

LENGTH,  OPERATOR  LLT  REFERENCED  GLCBALS: 

CONOCODE 


iflEUUB 


DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 

CHECK  TG  SEE  IF  THE  COMMAND  HAS  THE  DATA  SET  NAME. 
IF  THE  COMMANO  COMES  FROM  ANYWHERE  ELSE,  ALLOCATE  A 
NEW  OSNODE.  PRIMARILY  FOR  SELECT  AND  CREATE. 

INVOKED  PROCEDURES: 

ALLOCATE.OSNODE,  *NITIALIZE_OSNODE,  LIBRARY  CRASH, 
OPERATOR,  PARStNG,  TRAILING 

REFERENCED  GLQBALS: 

ORIGIN,  IMAGE,  BUFFER,  OPTION,  ADSET 

fiELAmf.-£Q5iIIQH 

DESCRIPTIVE  NOTES! 

LOGICAL  FUNCTION 

TRIES  TO  POSITION  THE  FILE  AT  THE  GIVEN  KEY.  SETS 
FLAG  ANO  SUB#  PROPERLY.  FIRST  SEE  IF  IN  CORE,  IF 
NOT  READING  THE  PLT«.  THEN  GET  THE  APPROPRIATE 
SECONDARY  LOGICAL  TRACK. 

INVOKED  PROCEDURES: 

BOAM,  GET_F ILE,  ISAM,  READ.FILE,  SYSTEM 
REFERENCED  GLOBALS: 

LTI,  DCB1 ,  DC82,  CURRENT,  LO,  HI,  ABUFF,  APAGE 

ASiOLUIL  ESIUIQH 


DESCRIPTIVE  NOTES: 

LOGICAL  FUNCTION 

GIVEN  THE  RECORO  NUMBER,  POSITIONS  THE  FILE  THERE. 
READ  IN  SEQUENCE  EACH  LT*  ANO  COUNT  HOW  .MANY  CAROS 
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THERE  ARE  UNTIL  ME  REACH  THE  APPROPRIATE  NUMBER. 

INVOKED  PROCEDURES: 

BDAM *  MOVE*  RE AO.FILE 

REFERENCED  GLOBAIS: 

LT#,  OCBl «  DCB2,  #T£XT»  SUBS*  ASUBS,  APAODING* 

SUB*,  RECORD#,  APAGE,  CURRENT 

DESCRIPTIVE  NOTES! 

LOGICAL  FUNCTION 

GET  THE  RECORO  CORRESPONDING  TO  THE  NEXT  KEY. 

SHOULD  MOVE  THE  CURRENT  KEY  INTO  THE  NEXT  KEY  AND 
AT  THE  END  MOVE  THE  NEXT  KEY  INTO  THE  CURRENT  KEY. 

INVOKEQ  PROCEDURES: 

BOAM,  GET.F ILE,  ISAM,  MOVE,  READ.FILE, 

RELATIVE. POSIT  ION 

REFERENCED  GLOBALS: 

NEXT.KEY,  CURRENT,  MAXKEY,  ABUFFER,  *SUBS,  LT#, 

OCBL ,  OCB2,  ABUFF,  SUB#,  APAGE 

LIBRARY  SEL££I 

DESCRIPTIVE  NOTES: 

SINGLE  SERVICE  REQUEST 

AFTER  INVESTIGATING  THE  DTOC  AND  PAGE,  UPDATE  THE 
OATE  SELECTED  FIELD  IN  THE  PAGE.  CHECK  IF  HIS  DATA 
SET  IS  STILL  LEGITIMATE.  POSITION  THE  FILE  AT  THE 
FIRST  RECORD  IF  IT'S  A  CARD  IMAGE  DATA  SET. 

INVOKED  PROCEDURES: 

BDAM,  GET.FILE,  INPUTER,  LOOK.AT.PAGE, 

LOOK_AT_TA8LE ,  MOVE,  OPERATOR,  WRITE.FILE 

REFERENCED  GLOBALS: 

LT#,  OCBl,  DCB2,  OATE.EXP,  OPTION,  SUB#,  APAGE, 
DATE. NOW ,  DATE.TOOAY,  #TEXT ,  ADSET,  NO_DATA_S£T , 
COUNT,  CONDCODE 

LJLB&iRYQRLAIL 

DESCRIPTIVE  NOTES: 

SINGLE  SERVICE  REQUEST 

CREATES  A  DATA  SET  BLOCK  AND  UPDATES  THt 
APPROPRIATE  PAGE.  CHECK  IF  PAGE  OVERFLOW  OCCURS  (NO 
DYNAMIC  MECHANISM  YETI.  WRITES  A  FREE  LOGICAL  TRACK 
IMAGE  WITH  THE  PROPER  FORMAT. 
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INVOKED  PROCEDURES: 

B0AM,  CR£AT£„DATA*.SET„BLOCX,  CREATE_LA8EL_BLGCK , 
GETTRKs  INPUTER,  LOOK_AT_PAGE ,  LGGK_AT_ TABLE,  MAP* 
MOVE  *  OPERATOR*  WRITE_FILE 

REFERENCED  GLOBALS: 

NO_DATA_SET,  ADSET*  CONDCODE,  LT#,  DCB1,  DCB2, 
COUNT,  HI,  CURRENT,  PAGE,  A_FREE_ IMAGE*  ABUFF, 
$8LK$,  iTEXT 

ULJ0.'’ABUi£EAlLti 

DESCRIPTIVE  NOTES: 

MULTI-SERVICE  REQUEST. 

SCRATCH  ALL  THE  LOGICAL  TRACKS  ASSOCIATED  WITH  THE 
DATA  SET.  THE  PAGE  DATA  SET  BLOCK  IS  WIPED  OUT 
FIRST.  THE  PLT  IS  DONE  THE  LAST. 

INVOKEO  PROCEDURES: 

BDAM,  GET.FILE,  INPUTER,  LOOK_AT_PAGE , 
IOOK„AT_TA0LE»  MOVE,  OPERATOR,  REINITIALIZE, 
WRITE_FILE 

REFERENCED  GLOBALS: 

COUNT,  DCBi «  QCB2,  PAGE,  LT#,  #SUBS,  APACOING, 
ADSET,  NO„OATA_SET,  CONDCODE 


DESCRIPTIVE  NOTES: 

BRANCHES  TO  ANY  PROCEDURE. 

INVOKEO  PROCEDURES: 

INLINE 


QjUl£iiXE£ 


DESCRIPTIVE  NOTES: 

MULTI-SERVICE  REQUEST.  BREAKS  UP  COMMANDS  INTO  ONES 
WITH  KEY  WORDS  OR  ONES  WITH  POSITIONAL  PARAMETERS. 
POSITIONS  THE  FILE  TO  APPROPRIATE  RECORD  THEN 
OUTPUTS  THE  BUFFER  TO  THE  APPROPRIATE  ROUTINES. 


INVOKEO  PROCEDURES: 

A8S0LUTE_PCSI TION,  BAD_BLOCK_S I ZE ,  BDAM, 
C0NVERT.8INARY,  OAT  A_SET_ERRQR,  GEI..F1LE, 

G2T_.R6C0RD*  INDEX1,  ISAM,  LEAOlNG,  L  I  BRARY_CR  ASH, 
LOOK. AT  TABLE,  MASS,  MOVE,  MOV^BYTES,  OPERATOR, 
PARSING,  REAO^FItE,  STRING,  ..UBSTR,  SYSTEM, 
TRAILING,  ZAP 


REFERENCED  GLOBALS: 

COUNT,  BUFFER#  APAGE,  AUSER_ NAME , 
iSUBS,  DCBI «  OCb2,  LT#,  AJ08, 


IMAGE,  SUBIOTYP, 
IOCOUNT,  TIMER, 
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ADSET,  ACURRENT 

UMABl.hASP 

DESCRIPTIVE  NOTES*. 

OUTPUTS  TO  THE  INTERNAL  READER  OF  HASP*  BLANK  OUT 
73-80*  IT  MILL  SCREW  UP  BASIC  PROGRAMS  BUT  HECK  IT 

INVOKED  PROCEDURES: 

OPERATOR*  ZAP*  STRING 

REFERENCED  GLOBALS: 

CONOCOOE*  HASP_USER»  BUFFER,  ABUFFER72 

UEMBY.mttl 

DESCRIPTIVE  NOTES: 

OUTPUTS  TO  THE  INTERNAL  READER  OF  HASP. 

INVOKEO  PROCEDURES: 

STRING 

REFERENCED  GLOBALS: 

CONOCOOE,  PRINT.USER,  BUFFER 

UJIBABIJSmij 

DESCRIPTIVE  NOTES: 

OUTPUTS  TO  THE  INTERNAL  READER  OF  HASP. 

INVOKED  PROCEDURES: 

STRING 

REFERENCED  GLOBALS: 

CONOCOOE,  PUNCH.USER,  BUFFER 

IJLfiBMI-JJIiBUI 

DESCRIPTIVE  NOTES: 

OUTPUTS  TO  THE  TERMINAL. 

INVOKEO  PROCEDURES: 

MOVE,  OPERATOR 

REFERENCED  GLOBALS: 

APAGE,  BUFFER 

UBBABY..1MSEBI 

w  CRIPTIVE  NOTES: 

INSERTS  A  CARO  IMAGE  INTO  A  USER'S  OATA  SET. 

MANOIES  TRACK  OVERFLOW  BY  WRITING  THE  LAST  IS  CAROS 
ONTO  A  NEW  TRACK. 


INVOKED  PROCEDURES: 
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BAO_BLOCK„SIZE»  BDAM,  C REA TE_LABEL„ BLOCK* 
OATA_SET_ERROR,  GET.FILE,  GETTRK,  ISAM,  MAP,  MOVE* 
OPERATOR,  READ_F ILE*  RELATIVE.POSITIQN,  WRITE_F ILE 

REFERENCED  GLOBALS: 

CURRENT,  LO,  #8LKS,  #TEXT *  ISUBS,  APAGE,  ABUFFER, 
APADDING,  LTI,  DCBI,  HI,  ABUFF,  A_FR£E_ IMAGE , 
BA0_8L0CK_SIZE.  BDAM,  BYTE,  COREBYTE 

££E£.S£M.liiS£fiI 

DESCRIPTIVE  NOTES: 

ALLOWS  TREE  FORM  FOR  INSERTION.  THE  SCAN  LOOKS  FOR 
THE  FIRST  NON-BLANK  SEQUENCE  OF  CHARACTERS  WITHIN 
COLUMNS  1  TO  8.  THE  FIRST  BLANK  AFTER  THE  NON-BLANK 
STRING  TERMINATES  THAT  STRING.  IT  BECOMES  THE  KEY. 
THE  NEXT  72  CHARACTERS  AFTER  THAT  BLANK  BECOMES  THE 
TEXT. 

INVOKEO  PROCEDURES: 

COREBYTE,  LEADING,  MOVE,  MOVEBYTES,  OPERATOR, 

STRING 

REFERENCED  GLOBALS: 

ABUFFER,  CONDCODE,  APAGE,  CURRENT 

DESCRIPTIVE  NOTES: 

DETERMINES  IF  STANOARD  COMMAND  MOOE  OR  KEYLESS 
MOOE.  IF  IT  IS  KEYLESS  MODE  THEN  DECIDE  TO  EITHER 
AUTOMATICALLY  GENERATE  THE  KEYS  OR  USE  THE 
FREE_SCAN_INSERT  TECHNIQUE  4  OPT  ION  'BASIC® ).  ThE 
SENTINEL  STRING  TERMINATES  THE  KEYLESS  MODE. 

INVOKED  PROCEDURES: 

BAO_BLOCK_SIZE,  BYTE,  CONVERT_B INARY ,  COREBYTE, 
DATA_SET_ERROR,  FREE_$CAN_INSERT ,  LEADING, 

LIBRARY_CRASH,  L l BRARY_ I NSERT ,  MOVE,  OPERATOR, 
PARSING, STRING,  SUBSTR,  TRAILING 

REFERENCED  GLOBALS: 

SUBIOTYP,  BUFFER,  COUNT,  COUNT2,  STOPKEY,  CURRENT 

0£l£I£.LQflf 

DESCRIPTIVE  NOTES: 

OELETES  CAROS  SU8X  TO  SUBY.  IF  THE  LAST  CARO 
OELETEO  WAS  THE  HI  KEY  THEN  WE  MUST  FIX  U,E  DSNOOE, 
THE  BLOCK  3  POINTER  ANO  THE  DIRECTORY  POINTERS.  IT 
IS  AN  INTERNAL  PROCEDURE  USING  INTERNAL  GLOBALS 
(SUBX,  SUBY,  ANO  SUB’). 

INVOKEO  PROCEDURES: 

BDAM,  GET.FILE,  ISAM,  MOVEBYTES,  STRING,  WRITE.FILE 
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REFERENCED  GLQBALS: 

BUFFER,  HI,  LTI,  OCB1,  PAGE 


DESCRIPTIVE  NOTES: 

EITHER  THERE  ARE  NO  CAROS  IN  THE  TRACK  OR  THERE  IS 
ONLY  ONE  LEFT.  FOR  CASE  1,  THROW  THE  TRACK  AWAY  AND 
REMOVE  IT  FROM  THE  DIRECTORY.  FOR  CASE  2,  SAVE  THE 
LAST  CARD,  THROW  THE  TRACK  AWAY,  AND  PUT  THE  LAST 
CARD  BACK  IN  (INSERT  WILL  AFFECT  TRACKS  AFTER  THE 
ONE  WE  HAVE  THROWN  AWAY). 

LIBRARY  DELETE 

DESCRIPTIVE  NOTES: 

MULTI-SERVICE  REQUEST. 

DELETES  A  CARD  IMAGE  FROM  THE  USER'S  OATA  SET. 

THERE  ARE  3  POSSIBLE  CASES.  THEY  ARE  THAT  THE  START 
AND  STOP  KEYS  ARE:  ON  THE  SAME  TRACK,  2)  ON 
ADJACENT  TRACKS,  OR  3)  SEPARATED  BY  I  OR  MORE 
TRACKS.  THE  ALGORITHM  IS  TO  TAKE  CASE  3,  REDUCE  IT 
TO  CASE  2.  TAKE  CASE  2  AND  REDUCE  IT  TO  CASE  I.  IN 
THIS  MANNER  THE  NUMBER  OF  DISK  READ/WRITES  IS 
MINIMIZED.  THE  FIRST  IMPLEMENTATION  DELETED  A  CARD 
AT  A  TIME.  THIS  IS  CLEARLY  SIMPLE  BUT  GROSSLY 
INEFFICIENT. 

INVOKED  PROCEDURES: 

BAO_BLOCK_SIZE,  BOAM,  QATA.SETJERROR ,  DELETE__LOOP, 
GET.FIIE,  ISAM,  LEADING,  L I 8RARY.CRASH, 

LIBRARY..  INSERT,  MOVE,  OPERATOR,  PARSING, 

REINITIALIZE,  STRING,  TRACK.UNDERFLOW,  WRITE.FILE 

REFERENCED  GLOBALS: 

LTI,  DCBl,  DCB2,  COUNT,  APAGE,  BUFFER,  IMAGE, 
SUBIOTYP 

LlBftABY.LXbA 

DESCRIPTIVE  NOTES: 

SELECTS  AN  XPL  LOAOABLE  OATA  SET  ANO  AUGMENTS  THE 
CONTROL  RECORO  WITH  THE  NUMBER  OF  LOGICAL  TRACKS  IN 
THE  OATA  SET.  THE  CONTROL  RECORO  IS  PASSEO  IN  THE 
BUFFER. 

INVOKEO  PROCEDURES: 

BUAM,  GET_F ILE,  L I BR  AR  Y_  SE  L  EC  T »  MOVE,  POST,  WAIT 
REFERENCED  GLQBALS: 

CONOCODE ,  OCB1 ,  0CB2,  LTI,  ISUBS,  ASUBS,  PAGE.BUFR 

LUft&A&X  LOAD 
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DESCRIPTIVE  NOTES: 

READS  IN  A  LOGICAL  TRACK  AND  TRANSFERS  THE  BLOCK  4 
OATA  TO  THE  AREA  POINTED  BY  AREALOC.  THE  SUB-BLOCK# 
IS  CONTAINED  IN  THE  COMMAND. 

INVOKED  PROCEDURES: 

BOAM,  CCNVERT_3INARY.  DAT A_S£T_ ERROR ,  GET.FILE, 
GET_INTO_PROT£CT_KEY_ZEROt 

GET_OUT_OF_PROT£CT-KEY_ZERO»  L I BRAR Y.CRASH,  MOVE, 
PARSING 

REFERENCED  GLGBALS: 

BUFFER,  DCBl,  IT#,  0SUBS ,  ABLK ,  ITEXT,  ,SUBS, 
AREALOC,  PAGE 

LlflftABY.flAfll 

DESCRIPTIVE  NOTES: 

WRITES  A  LOGICAL  TRACK  GIVEN  THE  KEY  IN  THE  COMMAND 
AND  TO  THE  AREA  POINTEO  BY  AR£ALQC. 

IF  THE  KEY  EXISTS,  REPLACE  IT  WITH  THE  NEW  IMAGE. 
OTHERWISE  FIX  THE  DIRECTORY  AND  WRITE  THE  NEW 
IMAGE. 

INVOKED  PROCEDURES: 

BDAM,  CREATE_cA8EL_8LOCK,  DATA__SET_ERROR ,  GET_FILE, 
GETTRK,  ISAM,  LEAOING,  LIBRARY.CRASH,  MAP,  MOVE, 
PARSING,  SYSTEM,  WRITE_F!LE 

REFERENCED  GLOBALS: 

BUFFER,  CURRENT,  DCBl,  0CB2,  CONDCOOE,  FREE  IMAGE, 
BUFF,  AREALOC,  PAGE,  LTi,  ABLK 

Li  MARY  NAME 

DESCRIPTIVE  NOTE5: 

CHANGES  THE  OATA  SET  NAME  IN  THE  DIRECTORY  PAGE  TO 
THE  NEW  NAME,  BUT  NOT  THE  INDIVIDUAL  TRACKS,  LOCK 
IN  PAGE  OATA  SET  TO  -1. 

INVOKED  PROCEDURES: 

INPUTER,  IQOK_AT_TABcE,  L0CK_AT-PACE ,  PARSING, 
OPERATOR,  BOAM,  MOVE,  WRITE_FU€ 

REFERENCED  GLOBALS: 

CONDCOOE,  COUNT,  ADSET,  PAOOING 

£&£  AJLfl&A&l  HAif 

DESCRIPTIVE  NOTES: 

PROVIDES  A  SINGLE  SERVER  FOR  HASP  REQUESTS.  THE 
•✓•EOF*  IS  A  HASP  INTERVAL  READER  CONVENTION.  MORE 
THAN  ONE  •/•EOF*  CARDS  ARE  USED  TO  FLUSH  The  OSAM 
BUFFER. 
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invoke o  procedures: 

L1BRARY.HASP,  MOVE,  OPERATOR,  QUTPUTER,  ZAP 
REFERENCED  GLOBALS: 

PUT.QUEUE,  HASP. USER,  TERMAO,  COUNT,  CONDCODE, 

BUFFER 

PRF  LIBRARY  PRINT 

DESCRIPTIVE  NOTES: 

USE  THE  SINGLE  SERVER  QUEUE  TECHNIQUE  BY  EXAMINING 
•PUT  QUEUE'.  IF  IT  IS  BUSY,  THEN  PASS  OVER  THE 
REQuisT.  NOTE  THAT  I  MI T I ALLY  PRINT,  PUNCH,  ANO  HASP 
SHARE  THE  QUEUE  I  SINCE  INTERNAL  REAOER  CAN  BE 
ALLOCATED  TO  ONLY  DNE  DO  CARO).  PRINT  JOB  BY 
GENERATING  JCL  CARDS.  LET  THE  DEFAULTS  BE  UH 
DEFAULTS.  NOTE  THAT  MORE  THAN  ONE  '/*EOF»  CARDS  ARE 
PASSED  TO  FLUSH  THE  QSAM  BUFFERS. 

INVOKEO  PROCEDURES: 

L I BRARY.PR I  NT ,  MOVEBYTES,  MOVER,  OPERATOR, 

OUTPUTER,  ZAP 

REFERENCED  GLOBALS: 

PUT. QUEUE,  PRINT.USER,  TERNAD,  COUNT,  CONOCODE, 
BUFFER 

PRP  i IBRARY  PUNCH 

OESCRIPTIVE  NOTES: 

USE  THE  SINGLE  SERVER  QUEUE  TECHNIQUE  BY  EXAMINING 
•PUT  QUEUE*.  IF  IT  IS  BUSY,  THEN  PASS  OVER  THE 
REQUIST.  NOTE  THAT  INITIALLY  PRINT,  PUNCH,  ANO  HASP 
SHARE  THE  QUEUE  (SINCE  INTERNAL  REAOER  CAN  BE 
ALLOCATED  TC  ONLY  ONE  00  CAROI.  PUNCH  JOB  BY 
GENERATING  JCL  CAROS.  LET  THE  OEFAULTS  BE  UH 
OEFAULTS.  NOTE  THAT  MORE  THAN  ONE  '/*E0F'  CARDS  ARE 
PASSED  TO  FLUSH  THE  QSAM  BUFFERS. 

INVOKEO  PROCEDURES: 

L ! BRARY. PUNCH,  MOVEBYTES,  MOVER,  OPERATOR, 

OUTPUTER,  ZAP 

REFERENCED  GLOBALS: 

PUT. QUEUE,  PUNCH.USER,  TERMAO,  COUNT,  CONOCOOE, 
BUFFER 

ISS  LlfllUMU 

DESCRIPTIVE  NOTES: 

INITIALIZES  THE  SYSTEM,  DETERMINES  THE  COMMANOS, 
HANOLES  THE  REQUEST  QUEUES.  (THREAD  THROUGH  QUEUE. 
UHEi  THE  LAST  ONE  IS  REACHED,  START  AGAIN.  IF  THERE 
ARt  NO  MORE,  MAI T  FOR  SOME  WORK  I .  MATCH  OUT  FOR 
00.  NANT  TERMINALS. 
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I NVOKfcO  PROCEDURES: 

ALL0CATE_CSNGDE,  FR££_OSNOO£»  INITIAL! ZE_OSNQOE , 

U BRARf.CREATE,  L IBRARY_0A0L ,  L I BRARY.OELETE , 
LI8RARY_0I SPLAY,  L  I  BRARY_HASP,  L ! BRARY_ INSERT , 
L18RARY_UNK,  L I  0R ARY_LCAO ,  L I BRARY.NAME , 

H  BRARY_ SCRATCH,  LIBRARY^ SELECT*  LOGGING,  MOVE, 
OPERATOR,  OUTPUTER,  POST,  PRE_LI BRARY^HASP , 
PRE_LIBRARY_ INSERT,  PRE_L IBRARY.PR INT , 

PRE.LIBRARV.PUNCH,  STRING,  SUBSTR,  SYSTEM,  WAIT, 


REFERENCED  GLOBALS: 

COUNT,  SUBIOTYP,  STATUS,  IOCOUNT,  CONTINUING, 
CONDCOOE,  BUFFER,  JOB,  NAME,  LIBTYPE,  IOSTAT, 
QUEUE  1 ,  POINTER 
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TME  FILE  MAINTENANCE  ROUTINES  CREATE  THE  LIBRARY  FILE, 
EXTRACTS  DISK  USAGE  DATA  FOR  THE  SYSTEM  MANAGER,  AND 
REORGANIZES  THE  MEMBERS  WITHIN  THE  FILE.  THESE  PROGRAMS 
MAINTAIN  THE  OATA  BASE  AS  AN  IBM  DIRECT  ACCESS  DATA  SET. 


ZEROOISK  INITIALIZES  A  DIRECT-ACCESS  OATA  SET  WITH  THE 
PROPERLY  FORMATTED  LOGICAL  TRACKS.  IT  IS  WRITTEN  IN  FORTRAN 
IV  AND  USES  AN  ASSEMBLY  LANGUAGE  PROGRAM,  WRITES.  WRITEQ  IS 
REQUIRED  TO  INITIALIZE  A  BOAM  OATA  SET  WITHOUT  KEYS. 

ZERODISK  HAS  TWO  PARTS,  u  >E  PART  READS  THE  DATA  CARDS, 
FORMATTING  THE  PROPER  TYPE  OF  LOGICAL  TRACK,  AND  THE  OTHER 
PART  WRITES  THE  FORMATTED  TRACKS  ONTO  DISK.  THE  INPUT  IS 
DIVIDED  INTO  3  PARTS,  ONE  SECTION  FOR  THE  DIRECTORY  TABLE  OF 
CONTENTS,  THE  NEXT  SECTION  FCR  THE  DIRECTORY  PAGES  ANO  THE 
LAST  SECTION  FOR  FREE  LOGICAL  TRAC  . 

EACH  SECTION  HAS  THE  SAN  STPJCTURE,  FOUR  BLOCKS  PER 
SECTION.  FOR  EACH  BLOCK  THERE  IS  A  FORMAT  CARD  AND  THE 
APPROPRIATE  OATA  CARDS  FOR  THAT  BLOCK.  THE  DESCRIPTION  OF 
EACH  BLOCK  IS  GIVEN  IN  OS  IMPLEMENT A ; ION  SECTION. 

AFTER  ALL  THE  INPUT  CAROS  HAVE  BEEN  READ,  ANO  IF  THERE 
ARE  NO  ERRORS,  THEN  THE  TRACKS  ARE  WRITTEN  IN  THE  FOLLOWING 
MANNERS  THE  FIRST  HALF  OF  THE  DATA  SET  IS  WRITTEN,  THEN  THE 
OIRECTORY  P* GES ,  ANO  FINALLY  THE  LAST  HALF  Oc  THE  DATA  SET. 
EACH  CYLINDER  HAS  THE  APPROPRIATE  LOGICAL  TRACKS  WITH  THE 
DTOC  LOGICAL  TRACK  ON  THE  FIRST  RECORD  OF  THE  NINETEENTH 
HEAD. 


FOR  EACH  TYPE  OF  LOGICAL  TRACK,  A  LISTING  OF  THE  FORMAT 
CAROS  ANO  THE  CORRESPONDING  DATA  CARDS  IS  PROVIDED.  THE  DATA 
IS  IN  HEXADECIMAL  AS  THEY  WOULD  APPEAR  ON  THE  DISK.  FINALLY, 
THE  FIRST  ICO  WORDS  Of  THE  RECORD  ARE  DUMPED  TO  VERIFY  THAT 
THE  FQRMATUNG  IS  PROPER. 


FILE  MAINTENANCE  ROUTINES.  NOVEMBER  7,  1969 


81 


SUTJUi* 

STATOISK  EXAMINES  EACH  LOGICAL  TRACK  IN  THE  UHTSS/2 
LIBRARY  DATA  SET  AND  PRINTS  INFORMATION  PERTINENT  TC  THAT 
TRACK.  THIS  PROGRAM.  WRITTEN  IN  FORTRAN.  IS  INTENDED  GNLY 
FOR  THE  SYSTEM  MANAGERS  SINCE  IT  VIOLATES  THE  SECURITY  LOCKS 
WITHIN  THE  SYSTEM. 

EACH  LOGICAL  TRACK  IS  READ  ANO  CLASSIFIED.  DEPENDING 
UPON  ITS  CLASSIFICATION,  THE  APPROPRIATE  INFORMATION  IS 
PRINTEO.  THE  MOST  IMPORTANT  INFORMATION  IS  THE  LOGICAL  TRACK 
POINTERS  IN  THE  DIRECTORIES.  ONLY  THE  CURRENT  DTOC  IS 
LISTED.  FINALLY  SOME  STATISTICS  REGARDING  THE  OISK 
UTILIZATION  ARE  LISTEO.  NQ1 c  THAT  LOCK  IS  AT  THE  MOMENT  JUST 
THE  LTf  OF  SOME  LOGICAL  TRACK  (USUALLY  ITSELF  EXCEPT  IN  SHE 
CASE  OF  DTOCSt. 

WHILE  THE  POSTING  FORMAT  IS  QUITE  OBVIOUS.  ONE  PART  OF 
THE  LISTING  MUST  BE  CLARIFIED?  THE  FORMAT  OF  A  BLOCK  3  MAP 
(AND  BLOCK  A)  IS  THE  NUMBER  OF  SUBBLOCKS,  THE  NUMBER  OF 
WORDS  IN  THE  DATA  AREA.  THE  NUMBER  OF  WORDS  IN  THE  KEY  AREA. 
AfiO  THE  NUMBER  OF  WORDS  IN  THE  LOCK  AREA. 

NOTE  THAT  THE  PERCENTAGE  OF  TRACKS  USED  MAY  BE  THE  SAME 
AS  THE  SUM  OF  THE  PERCENTAGES  FOR  PAGE.  DTOC.  USER  LOGICAL 
TRACKS  (FOR  THE  MOMENT  THE  ONLY  REASON  IS  THAT  INITIALLY 
SOME  TRACKS  WERE  ALLOCATED  FOR  FUTURE  USE.  FOR  THE  101 
CYUNOER  FILE,  2  CYLINDERS  WERE  SAVED  FOR  PAGE  OVERFLOW 
TRACKS  1 . 
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AflUfllS* 

THE  PURPOSE  OF  ANLZOISK  IS  TC  PROVIDE  A  SYSTEMS 
MANAGEMENT  TOOL  WHICH  MAY  BE  USEO  TO  EXTRACT  UTILIZATION 
INFORMATION  CONTAINED  WITHIN  THE  LIBRARY  FILE.  THE  INPUT  IS 
A  SET  OF  DATA  CAROS  SPECIFYING  WHETHER  A  GIVEN  DATA  SET 
SHOULD  8E  SAVED  OR  SCRATCHED.  THE  OUTPUT  IS  A  LIST  OF  DATA 
SETS  WHICH  WILL  EXPIRE  WITHIN  A  WEEK  FROM  THE  DATE  THE 
PROGRAM  WAS  RUN,  A  LIST  OF  DATA  SETS  WHICH  HAVE  BEEN 
SCRATCHED,  AND  TRACK  UTILIZATION  FaCTS  FOR  EACH  DATA  SET. 
THE  TRACK  UTILIZATION  FACTS  CONTAIN  THE  USE  COUNT  OF  EACH 
LOGICAL  TRACK  AND  THE  NUMBER  OF  BYTES  USEO  IN  THAT  TRACK. 

THE  PROGRAM  IS  SO  STRUCTURED  AS  TO  ENABLE  THE  UHTSS 
MANAGER  TO  EXTRACT  ANY  INFORMATION  CONTAINED  ON  THE  LIBRARY 
FILE.  WHILE  AT  THE  PRESENT  TIME  THE  PROGRAM  ALLOWS  MAINLY 
FOR  AUTOMATIC  CHECKING  ANO  SCRATCHING  OF  DATA  SETS,  IT  CANBE 
EEASILY  MODIFIED  TO  EXTRACT  SPECIFIC  INFORMATION  THE  SYSTEM 
MANAGER  MAY  REQUEST. 

THE  UTILITY  PROGRAM  WILL  PROVIDE  A  LIST  OF  DATA  SETS 
WHICH  WILL  EXPIRE  WITHIN  A  WEEK  FROM  THE  DATE  THE  PRORAM  IS 
RUN  (USING  CHECK_D4TE1.  UNLESS  AN  EXTENSION  OF  THE 
EXPIRATION  DATE  IS  MEQUESTEO  BY  THE  USER,  THE  DATA  SET  WILL 
THEN  BE  AUTOMATICALLY  SCRATCHED  THE  NEXT  TIME  THE  ANLZOISK 
PROGRAM  IS  RUN  (A  TWO  WEEK  GRACE  PERIOD  IS  PRGVIOEC  HOWEVER, 
BEFORE  ACTUALLY  SCRATCHING  THE  DATA  SET).  AN  OVERRIDE 
FEATURE  IS  PROVIOEO.  THIS  FEATURE  IS  A  SCRATCH/SAVE  LIST 
WHICH  IS  A  SET  OF  OATA  CAROS  HAVING  THE  DATA  SET  NAME  IN 
COLUMN  ONE,  THE  JOB/ ACCOUNT  NUMBER  IN  COLUMN  TEN,  AND  THE 
SCRATCH/SAVE  CODE  IN  COLUMN  TWENTY  (SCRATCH*!  AND  SAVE*  • 
*  ). 


IN  ADDITION  TO  THE  ABOVE  FUNCTIONS,  THE  PROGRAM  ALSO 
PRINTS  EACH  OATA  SET  NAME,  JOB/ACCOUNT  NUMBER,  PROGRAMMER'S 
NAME  ANO  THE  ASSOCIATED  PAGE  WITH  THE  PRIMARY  AND  SECONDARY 
LOGICAL  TRACK  NUMBERS,  AS  WELL  AS  THE  NUMBER  OF  TIMES  THE 
SECONDARY  LOGICAL  TRACK  HAS  BEEN  USEO  AND  HOW  MANY  BYTES  IT 
CONTAINS. 

THE  FUNCTION  OF  ACHTUNG  IS  TO  PROVIDE  A  MESSAGE 
DIRECTORY  OF  THE  SYSTEM.  TWO  PARAMETERS  ARE  PASSED,  THE 
FIRST  BEING  A  VARIABLE  AND  THE  SECOND  AN  ERROR  CCDE.  TEN 
BASIC  COOES  ARE  PROVIDEO  DIFFERING  BY  THE  POSITION  OF  THE 
VARIABLE  WITHIN  THE  MESSAGE  ANO  THE  SEVERITY  LEVEL  (BLANK 
(il,  NOTE  (3),  WARNING  (3),  SEVERE  ERROR  (3)). 

THE  FUNCTION  OF  SCRAICH-IT  IS  TO  ERASE  A  SPECIFIED  DATA 
SET  ANO  TO  PROVIOE  A  MESSAGE  TO  THAT  EFFECT.  THE  PARAMETER 
IS  THE  OATA  SET  NAME. 
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